tipo - ¿Vale la pena utilizar tinyint en lugar de int para las tablas de búsqueda SqlServer?

tipos de datos sql server (5)

¿Algún otro problema?

No estoy seguro si este es el tipo de "gotcha" que quiere decir, pero me he encontrado con situaciones en las que usar un datetime en lugar de un smalldatetime daba un comportamiento funcional incorrecto, porque la menor precisión smalldatetime no se podía comparar con el fecha de alta precisión para dos fechas que de otro modo serían "lo mismo".

No hay posibilidad de que eso ocurra aquí, ya que un tinyint / smallint / int / bigint se compararán como idénticos para el mismo valor numérico entero. Entonces, obviamente, estás a salvo en ese aspecto, no es que responda exactamente tu pregunta.

Al diseñar una tabla de búsqueda (enum) en SqlServer 2005, si sabe que el número de entradas nunca será muy alto, ¿debería usar tinyint en lugar de int? Lo que más me preocupa es el rendimiento, especialmente la eficiencia de los índices.

Digamos que tienes estas tablas representativas:

Person ------ PersonId int (PK) PersonTypeId tinyint (FK to PersonTypes)

PersonTypes ----------- PersonTypeId tinyint PersonTypeName varchar(50)

Los factores obvios son el tamaño de los datos y la molestia de codificación. Cuando llegamos a 100 millones de filas en la tabla de personas, estamos almacenando 300 millones de bytes menos con tinyint en comparación con int, más el espacio ocupado por nuestros índices. No es una gran cantidad de datos, pero es importante si la decisión de diseño se aplica a docenas de tablas grandes. La molestia de codificación, por supuesto, viene de todos esos problemas de conversión en el código ASP.NET C # / VB.

Si dejamos de lado esos dos problemas, ¿qué más entra en juego? ¿Las consultas serán mucho más eficientes debido al tamaño reducido de las páginas de índice? ¿O hay algún tipo de amortiguación que sucede que simplemente negará los beneficios? ¿Algún otro problema?

Siempre he usado Ints personalmente, pero estoy considerando la posibilidad de un próximo esfuerzo de rediseño / migración en algunas mesas enormes, así que me gustaría obtener algunos consejos.

[Editar]

Después de experimentar con esto, las molestias de codificación que anticipé resultaron ser un problema. Cambiar de int a tinyint no ha producido ningún problema de conversión.

Cuanto más angosta sea una tabla (o entrada de nodo de índice), más registros (o nodos de índice) pueden caber en una sola página de E / S, y las operaciones de IO de lecturas físicas (y lógicas) son menos necesarias para cualquier consulta. Además, cuantos más nodos de índice haya en una sola página, habrá menos niveles en el índice, desde el nivel raíz hasta el nivel de hoja, y si al hacer una tabla más estrecha pasa el umbral donde el índice puede ser un nivel más pequeño, esto puede tener un efecto dramático en perforamnce.

Si al cambiar a TinyInt cambia su tabla de 200 bytes de ancho a 197 bytes de ancho, probablemente no haga ninguna diferencia ... Pero si la cambia de 20 bytes a 14, (digamos que tiene 2 entradas), entonces podría ser dramático ...

Dudo que el uso de smallint en lugar de int vaya a tener mucho beneficio en el rendimiento, excepto en los casos más extremos. Sin embargo, puede crear fácilmente una aplicación de prueba para esto, crear algunas tablas de prueba y hacer un millón de inserciones / actualizaciones / selecciones y comparar el rendimiento.

Memoria 101: Cosas más pequeñas significa tener más memoria RAM al mismo tiempo y, por lo tanto, menos lecturas de disco duro. Si la base de datos es lo suficientemente grande y está ejecutando cierto tipo de consultas, este podría ser un factor muy serio. Pero probablemente no hará una gran diferencia.

También existe el factor de mantener los índices / copias de seguridad de disco / copias de seguridad en cinta, que también ocupan espacio, pero yo diría que lo más importante es el rendimiento de IO y memoria.