En los esquemas de base de datos, a menudo me doy cuenta de que los tamaños de VARCHAR se redondean a las compensaciones de bytes 128/256 o 4096. También lo he hecho antes, y la idea subyacente probablemente fue algo eficiente.
Sin embargo, ¿todavía hay una razón válida para hacerlo hoy en día? A menudo utilizo '50', '100' o '200' como tamaños VARCHAR en estos días, ya que son más naturales y, por lo general, también se muestran en las verificaciones 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 de forma secuencial, y los tamaños no se redondean a una potencia de 2, es posible que algunos elementos deban "dividirse" en dos páginas. en el disco duro (por ejemplo, los primeros 10 bytes en la página n y los siguientes 40 bytes en la página n + 1), lo que en algunos casos puede llevar a dos lecturas del disco duro en lugar de una.
Más probable es que el punto de @Jan Hudec dice que muchos programadores piensan que "128" o "256" son "números redondos agradables", lo que los convierte en una opción más natural que los números impares como 137, 19 o 100. >
En general, no hay razón para esas longitudes de columna. No habrá mejora de rendimiento de una columna varchar (100) en comparación con una columna varchar (128).
Sin embargo, volvería a revisar 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:
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) que aprendí a usar potencias de 2 para longitudes de matriz y columna. Hubo una justificación de que era "más rápido" debido a que la implementación podría usar cambio de bits. Si es verdad ya es una pregunta abierta. ¿Alguien tiene alguna idea de si aún es válido?
Por cierto, he movido los anchos de columna al número uniforme b / c, es extraño decirle 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.
Es probable que realmente no importe, ya que en realidad solo verías un poco de eficiencia de almacenamiento si el tamaño de tu fila completa fuera una potencia de 2. Es posible que seguir con potencias de 2 pueda 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 un tamaño de potencia de 2 [según la base de datos]), pero no lo convertiría en una regla rígida y rápida. / p>
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 encajen dentro de un bloque de almacenamiento (cualquiera que sea su base de datos para el almacenamiento en disco). ) Te ganaría algo.
Si bien no estoy familiarizado con todos los sistemas DBMS, la unidad de almacenamiento "física" más pequeña de Oracle es un "bloque" que, de forma predeterminada, tiene un tamaño de 2 KB. La práctica de ajustar el tamaño de sus columnas en potencias de dos es parte de una práctica más amplia de ajustar el tamaño de sus filas para que se ajusten correctamente a 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, haciendo que la lectura, inserción y escaneo consuman más tiempo que si pudiera ajustar cada fila en un bloque (y solo tienen una fila en cada bloque). Esa, al menos, es la razón histórica de ello. Hoy en día, la mayoría de las personas considera que esta práctica es una suboptimización.
Lea otras preguntas en las etiquetas database database-design