Usar un tamaño de columna mucho más grande de lo necesario

Estoy creando una base de datos SQL Server con otra persona. Una de las tablas es pequeña (6 filas) con datos que probablemente permanecerán constantes. Existe la posibilidad remota de que se agregue una nueva fila. La tabla se ve así:

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

Estoy mirando la longitud del char de eso name columna, y creo que sus valores probablemente nunca serán mayores que, digamos, 32 caracteres, tal vez ni siquiera mayores que 24. ¿Hay alguna ventaja en cambiar esta columna a, por ejemplo, varchar(32)?

Además, ¿hay alguna ventaja en mantener los tamaños de columna predeterminados en múltiplos de 4, 8, 32, etc.?

SQL Server usa longitudes de columna al asignar memoria para el procesamiento de consultas. Entonces, sí, en resumen, siempre debes dimensionar las columnas de manera adecuada para los datos.

Las asignaciones de memoria se basan en el número de filas devueltas por la consulta multiplicado por la mitad de la longitud declarada de la columna.

Dicho esto, en este caso donde tienes 6 filas, probablemente no quieras optimizar de forma prematura. A menos que UNE esta tabla a otra con millones de filas, no habrá una gran diferencia entre un varchar (24) y un varchar (32), o incluso un varchar (128).

Su segunda pregunta se refiere a la alineación de longitudes de columna en múltiplos binarios. Eso no es necesario ya que SQL Server almacena todos los datos en páginas de 8 KB, independientemente de la longitud de cada columna.

Con 6 filas, no, no habrá beneficio observable. Esa tabla completa se ajustará en una sola página, por lo que reducir el espacio potencial máximo que usará en esa página y, al mismo tiempo, ocupar toda la página no es realmente diferente en todo sentido práctico.

Sin embargo, en tablas más grandes, el tamaño correcto es crucial. La razón es que las estimaciones de memoria se basarán en el supuesto de que cada valor estará poblado al 50%. Entonces, si tiene varchar (128), cada valor esperará ocupar 64 bytes, independientemente de los datos reales, por lo tanto, las concesiones de memoria serán 64b * número de filas. Si todos los valores serán de 32 caracteres o menos, probablemente sea una mejor opción convertirlo en varchar (64) o incluso varchar (32). Si un gran porcentaje de valores está cerca o en el límite, incluso podría argumentar a favor de que el carbón elimine la volatilidad.

En cuanto a los beneficios de tener longitudes de cuerda limitadas a potencias de 2, no creo que en el hardware de hoy alguien pueda demostrar ninguna ventaja obvia.