¿Hay alguna ventaja en configurar los campos tinyint cuando sé que el valor no excederá 255?

Question

¿Debo elegir el tipo de datos más pequeño posible, o si estoy almacenando el valor 1, por ejemplo, no importa cuál sea el tipo de datos col y el valor ocupará el mismo tamaño de memoria?

La pregunta también es, porque siempre tendré que convertirlo y jugar en la aplicación.

---

ACTUALIZAR

Creo que varchar (1) y varchar (50) tienen el mismo tamaño de memoria si el valor es '' a '', pensé que es lo mismo con int y tinyint, de acuerdo con las respuestas que entiendo que no es así, ¿verdad?

Answer 1

Elija siempre el tipo de datos más pequeño posible. SQL no puede adivinar cuál desea que sea el valor máximo, pero puede optimizar el almacenamiento y el rendimiento una vez que le indique el tipo de datos.

---

Para responder a su actualización:

varchar ocupa solo la cantidad de espacio que usa y tiene razón cuando dice que el carácter " a " ocupará 1 byte (en codificación latina) sin importar qué tan grande elija un campo varchar . Ese no es el caso con ningún otro tipo de campo en SQL.

Sin embargo, es probable que sacrifiques la eficiencia por el espacio si haces de todo un campo varchar. Si todo es un campo de tamaño fijo, entonces SQL puede hacer una simple multiplicación de tiempo constante para encontrar su valor (como una matriz). Si tiene campos varchar allí, entonces la única forma de averiguar dónde se almacenan sus datos es revisar todos los campos anteriores (como una lista vinculada).

Si está comenzando SQL, le aconsejo que se mantenga alejado de los campos varchar a menos que espere tener campos que a veces tienen cantidades muy pequeñas de texto y otras muy grandes (como publicaciones de blog). Se necesita experiencia para saber cuándo usar campos de longitud variable para el mejor efecto e incluso yo no lo sé la mayor parte del tiempo.

Answer 2

Es una consideración de rendimiento particular para el diseño de su sistema. En general, cuantos más datos pueda incluir en una página de datos de SQL Server, mejor será el rendimiento.

Una página en SQL Server es 8k. El uso de pequeños ints en lugar de ints le permitirá colocar más datos en una sola página, pero debe considerar si vale la pena o no. Si vas a servir miles de visitas por minuto, entonces sí. Si este es un proyecto de pasatiempo o algo que solo unas pocas docenas de usuarios verán, entonces no importa.

Answer 3

La ventaja está ahí, pero podría no ser significativa a menos que tenga muchas filas y realice la pérdida de operación. Habrá una mejora en el rendimiento y un almacenamiento más pequeño.

Answer 4

Tradicionalmente cada bit guardado en el tamaño de la página significaría un poco de mejora de la velocidad: filas más estrechas significan más filas por página, lo que significa menos memoria consumida y menos solicitudes de E / S, lo que resulta en una mejor velocidad. Sin embargo, con SQL Server 2008 compresión de página las cosas comienzan a ponerse borrosas. El algoritmo de compresión puede comprimir entradas de 4 bytes con valores inferiores a 255 en incluso menos de un byte.

Los algoritmos de compresión de fila almacenarán un byte int de 4 bytes en un byte único para valores inferiores a 127 (int está firmado), 2 bytes para valores inferiores a 32768 y así sucesivamente.

Sin embargo, dado que las buenas funciones de compresión solo están disponibles en los servidores Enterprise Edition, tiene sentido mantener el hábito de usar el tipo de datos más pequeño posible.