¿Hay alguna razón para usar longitudes de Base2 para columnas en SQL Server?

duplicados posibles:
varchar Fields - Is a Power of Two More Efficient?
Nvarchar or varchar what is better use multiply of 2 or rounded full numbers??¿Hay alguna razón para usar longitudes de Base2 para columnas en SQL Server?

Por pura costumbre que definen los tamaños de las columnas que uso en SQL Server para ser Base2 tamaños. Por ejemplo, he aquí una tabla que estoy trabajando en:

int Id
FirstName nvarchar (64)
Apellido nvarchar (64)
Col4 varchar (16)
COL5 nvarchar (32)
Col6 nvarchar (128)
etc ...

No tengo idea de dónde vino este hábito, y no estoy seguro de que tenga sentido. ¿La siguiente definición de tabla sería menos eficiente de alguna manera que la anterior?

int ID
FirstName nvarchar (50)
LastName nvarchar (50)
Col4 varchar (10)
nvarchar COL5 (30)
nvarchar Col6 (100)
etc ...

I guess my main questio n es: ¿hay alguna razón legítima para usar longitudes de columna Base2?

Fuente

2010-10-19 travis

posible duplicado de [campos varchar -? Es una potencia de dos más eficiente] (http://stackoverflow.com/questions/593364/varchar-fields-is-a-power-of-two-more-efficient) o esta http://stackoverflow.com/questions/1374958 – gbn

buenos hallazgos @gbn, supongo que esto es una víctima – travis

no puedo creer que esta pregunta tiene múltiples duplicados –

Hacer columnas más grande de lo que necesitan para estar activamente puede ser perjudicial para el diseño de su base de datos. De BOL:

Una tabla puede contener un máximo de 8,060 bytes por fila. En SQL Server 2008, esta restricción se relaja para las tablas que contienen columnas de tipo varchar, nvarchar, varbinary, sql_variant o CLR definidas por el usuario ... Superar el límite de 8,060 bytes del tamaño de fila podría afectar el rendimiento porque SQL Server aún mantiene una límite de 8 KB por página. Cuando una combinación de varchar, nvarchar, varbinary, sql_variant, o columnas de tipo definido por el usuario CLR excede este límite, el motor de base de datos SQL Server mueve la columna de la ficha con el ancho más grande a otra página en la unidad de asignación ROW_OVERFLOW_DATA, mientras se mantiene un 24- puntero de bytes en la página original. Mover registros grandes a otra página se produce dinámicamente a medida que los registros se alargan según las operaciones de actualización. Las operaciones de actualización que acortan los registros pueden hacer que los registros vuelvan a la página original en la unidad de asignación IN_ROW_DATA. Además, consultar y realizar otras operaciones de selección, como ordenaciones o uniones en registros grandes que contienen datos de desbordamiento de fila, ralentiza el tiempo de procesamiento, ya que estos registros se procesan de forma síncrona en lugar de asincrónicamente.

He encontrado si les das el tamaño adicional, tarde o temprano lo usarán. Además, si configura algo como varchar (64) y solo necesita 10 caracteres como máximo, está haciendo que sea más probable que alguien use el campo para fines distintos a los previstos y encontrará que obtendrá datos incorrectos en esos campos (como un campo de número de teléfono que contiene notas sobre la secretaria de la oficina para contactar y elegir un ejemplo no tan aleatorio).

Sin embargo, al menos, este diseño es mucho mejor que hacer que todo nvarchar (max).

Fuente

2010-10-19 17:19:52 HLGEM

varchar (64) en lugar de varchar (10) es un mal ejemplo porque varchar (16) se habría utilizado en ese caso, que solo desperdicia 4 bytes de espacio. varchar (512) en lugar de varchar (300) sería un mejor ejemplo de espacio desperdiciado que podría ser objeto de abuso para almacenar una gran cantidad de datos adicional que no estaba destinado a ser en esa columna – Dan

números de teléfono de los Estados Unidos a menudo se almacenan en varchar (10) - 3 dígitos para el código de área, 3 dígitos para el prefijo y 4 dígitos para el sufijo. Si necesita almacenar números de teléfono internacionales y almacena las partes no numéricas del número que podrían ser diferentes. – HLGEM

No, es solo el hábito de un programador pensar y actuar en potencias de 2; no hay ninguna razón técnica por parte de SQL Server para hacer esto, no hay aumento en la velocidad o el rendimiento ni nada por el estilo.

Fuente

2010-10-19 16:24:23

Dudoso. En primer lugar, las longitudes exactas de las columnas son importantes principalmente para sus propios motivos de esquema de datos. En segundo lugar, si las longitudes entran en eficiencias, la longitud total de todas las columnas es probablemente el criterio más importante, e incluso entonces, habrá gastos generales de contabilidad que significarán que un buen número redondo no es la mejor respuesta.

Así que puede encontrar consejos sobre cómo limitar el tamaño de su fila a una cantidad determinada, para que toda la fila se ajuste a una página, o algo similar. Esto es para reducir el número de E/S de disco por registro. Pero los tamaños de columnas individuales no importan, sería el total lo que hace.

Fuente

2010-10-19 16:24:29

No es específicamente una pregunta de SQL SErver ... Hago lo mismo en Oracle y MySQL. No hay ninguna razón en particular más que el hecho de que tal vez me siento más cómodo usando tamaños base2.

Fuente

2010-10-19 16:24:44

No hay razón para hacer esto, especialmente con (n) datos varchar, donde el tamaño de almacenamiento es la longitud real de los datos + 2 bytes.

Fuente

2010-10-19 16:25:08

¿Hay alguna razón para usar longitudes de Base2 para columnas en SQL Server?

Respuesta

Cuestiones relacionadas