varchar Fields - ¿Es una potencia de dos más eficiente?

Question

¿Es más eficiente usar un campo de tamaño varchar con una potencia de dos en comparación con otro número? Estoy pensando que no, porque para SQL Server el valor predeterminado es 50.

Sin embargo, he oído (pero nunca lo he confirmado) que el tamaño de los campos como potencia de 2 es más eficiente porque equivalen a incluso bytes y computadoras proceso en los bits & bytes.

Entonces, ¿un campo declarado como varchar(32) o varchar(64) tiene algún beneficio real sobre varchar(50)?

Answer 1

Nº

En algunos otros usos, hay algunas ventajas de utilizar estructuras con una potencia de dos tamaño, sobre todo porque se puede ajustar una agradable (potencia de dos) el número de éstos dentro de otro poder- de la estructura de dos dimensiones. Pero esto no se aplica a un tamaño de campo DB.

El único poder-de-dos-tamaños relacionado con VARCHARs es sobre el tipo exacto de varchar (o TEXT/BLOB en algunos dialectos de SQL): si es menos de 256, puede usar un solo byte para indicar la longitud. si es menos de 65536 (64 KB), dos bytes son suficientes, tres bytes funcionan hasta 16777216 (16 MB), cuatro bytes van a 4294967296 (4 GB).

Además, se puede argumentar que VARCHAR(50) es tan caro como VARCHAR(255), ya que ambos necesitarán n + 1 bytes de almacenamiento.

Por supuesto que es antes de pensar en Unicode ...

Answer 2

Siempre pensé que la gente elegía poderes de dos para los campos varchar porque somos geeks y eso es lo que hacemos. Al menos eso es lo que siempre he hecho.

Answer 3

Depende de la implementación de la base de datos específica, pero no lo esperaría. Por lo general, no realiza ningún cálculo sobre la cantidad de caracteres, por lo que no debería afectar el rendimiento, solo el espacio.

Answer 4

El único beneficio tangible que verá al utilizar ciertas longitudes máximas es el espacio de almacenamiento requerido para el VARCHAR. Una longitud máxima de más de 255 requeriría un byte adicional para almacenar la longitud del valor en cada fila (y 2 bytes adicionales para longitudes de 256^2 o más, y así sucesivamente).

Answer 5

¿Para SQL en general? No. Para una implementación específica, tal vez.

Lo que es más eficiente no está determinado por una especificación (SQL es solo una especificación), sino cómo se implementa en un determinado DBMS.