Использование размера столбца намного больше, чем необходимо

Я создаю базу данных SQL Server с кем-то еще. Одна из таблиц небольшая (6 строк) с данными, которые, вероятно, останутся неизменными. Существует небольшая вероятность того, что будет добавлен новый ряд. Таблица выглядит примерно так:

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');

Я смотрю на длину символа в этом nameстолбце и думаю, что его значения, вероятно, никогда не будут больше, скажем, 32 символа, может быть, даже не больше 24. Есть ли какое-либо преимущество в том, что я изменил этот столбец на например varchar(32)?

Кроме того, есть ли преимущество в том, чтобы размеры столбцов по умолчанию были кратны 4, 8, 32 и т. Д.?

SQL Server использует длины столбцов при выделении памяти для обработки запросов. Итак, да, короче говоря, вы должны всегда подбирать столбцы в соответствии с данными.

Выделение памяти основано на количестве строк, возвращаемых запросом, умноженном на половину объявленной длины столбца.

Сказав это, в этом случае, когда у вас есть 6 строк, вы, вероятно, не хотите преждевременной оптимизации. Если вы не присоедините эту таблицу к другой с миллионами строк, не будет большой разницы между varchar (24) и varchar (32), или даже varchar (128).

Ваш второй вопрос касается выравнивания длин столбцов по двоичным кратным. Это вовсе не требуется, поскольку SQL Server хранит все данные на страницах размером 8 КБ независимо от длины каждого столбца.

С 6 рядами нет, заметной выгоды не будет. Вся эта таблица будет помещаться на одной странице, поэтому уменьшение максимального потенциального пространства, которое вы будете использовать на этой странице, в то же время занимая всю эту страницу, практически не отличается во всем практическом смысле.

Однако на больших столах правильное определение размера имеет решающее значение. Причина в том, что оценки памяти будут основаны на предположении, что каждое значение будет заполнено на 50%. Таким образом, если у вас есть varchar (128), каждое значение будет занимать 64 байта, независимо от фактических данных, поэтому предоставление памяти будет 64b * число строк. Если все значения будут состоять из 32 символов или менее, возможно, лучшим выбором будет сделать его varchar (64) или даже varchar (32). Если большой процент значений близок к предельному значению или находится на его пределе, вы можете даже потребовать, чтобы char убрал из него волатильность.

Что касается преимуществ ограничения длины строк до степени 2, я не думаю, что на сегодняшнем оборудовании кто-либо может продемонстрировать какие-либо очевидные преимущества.