¿Hay alguna razón para usar los tamaños VARCHAR redondeados a un desplazamiento de 128/256/4096 bytes?

En los esquemas de la base de datos, a menudo noto que los tamaños de VARCHAR se redondean a los desplazamientos de bytes 128/256 o 4096. También lo he hecho antes, y la idea detrás de esto probablemente fue algo con eficiencia.

Sin embargo, ¿hay alguna razón válida para hacerlo hoy en día? A menudo uso '50', '100' o '200' como tamaños VARCHAR en estos días, ya que son más naturales y generalmente también se muestran en las comprobaciones de validación para el usuario.

La única explicación racional que se me ocurre sería: si el DBMS almacena los valores de una columna secuencialmente, y los tamaños no se redondean a una potencia de 2, entonces algunos elementos pueden tener que "dividirse" en dos páginas en el disco duro unidad (por ejemplo, los primeros 10 bytes en la página ny los siguientes 40 bytes en la página n + 1), lo que en algunos casos puede conducir a dos lecturas del disco duro en lugar de una.

Más probable es el comentario de @Jan Hudec de que muchos programadores piensan que "128" o "256" son "buenos números redondos", lo que los convierte en opciones más naturales que los números impares como 137, 19 o 100.

En general, no hay razón para esas longitudes de columna. No habrá mejora en el rendimiento de una columna varchar (100) versus una columna varchar (128).

Sin embargo, volvería a verificar el sistema de base de datos que está utilizando para obtener más aclaraciones sobre las restricciones y otras advertencias específicas del proveedor.

Por ejemplo, aquí hay un buen ejemplo de una restricción del sistema de base de datos para SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

La longitud total de la fila es más importante que las longitudes de columna individuales.

No recuerdo si era un DBMS o un compilador, pero sí recuerdo (hace mucho tiempo) aprender a usar potencias de 2 para longitudes de columnas y matrices. Había una justificación de que era "más rápido" debido a que la implementación podría utilizar el desplazamiento de bits. Si ya es verdad es una pregunta abierta. ¿Alguien tiene alguna idea sobre si todavía es válido?

Por cierto, he movido los anchos de columna al número uniforme b / c, es extraño decirles a los usuarios que el límite de caracteres es de 256 caracteres.

Y algunas bases de datos muy antiguas lo limitaron a 256 columnas de ancho de caracteres.

Probablemente no importe realmente, ya que realmente solo vería un poco de eficiencia de almacenamiento si el tamaño de toda su fila fuera una potencia de 2. Es posible que quedarse con potencias de 2 podría hacer que sea más probable que el tamaño de su fila funcionaría a una potencia de dos (ya que la mayoría de los tipos de datos nativos tienden a tener una potencia de 2 (dependiendo de la base de datos)), pero no lo convertiría en una regla estricta.

Podría tener más sentido si estuviera trabajando con columnas grandes (4K o más grandes), ya que posiblemente podrían almacenarse por separado y dimensionarlas para que quepan dentro de un bloque de almacenamiento (lo que sea que su base de datos use para el almacenamiento en disco) usted algo

Si bien no estoy familiarizado con todos los sistemas DBMS, la unidad de almacenamiento "física" más pequeña en Oracle es un "bloque" que por defecto tiene un tamaño de 2 KB. La práctica de dimensionar sus columnas en potencias de dos es parte de una práctica más amplia de dimensionar sus filas para que quepan adecuadamente en los bloques de almacenamiento. Cambiar el tamaño de las columnas para que una fila requiera un byte más que el tamaño del bloque requeriría que se asignen dos bloques y su fila también abarcaría dos bloques, lo que hace que leer, insertar y escanear requiera más tiempo que si pudiera encajar cada fila en un bloque (y solo tiene una fila en cada bloque). Esa, al menos, es la razón histórica para ello. Hoy en día, la mayoría de las personas consideran que esta práctica es una suboptimización.