Використання розміру стовпчика набагато більше, ніж потрібно

Я створюю базу даних 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 рядків, ви, мабуть, не хочете переоцінювати передчасно. Якщо ви не приєднаєте цю таблицю до іншої з мільйонами рядків, між варчаром (24) і варчаром (32) або навіть варчаром (128) не буде великої різниці.

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

З 6 рядів, ні, користь, яка не спостерігатиметься, не буде. Ціла таблиця розміститься на одній сторінці, тому знизивши максимальний потенційний простір, який ви будете використовувати на цій сторінці, все ще займаючи цю всю сторінку, насправді нічим не відрізняється в практичному сенсі.

Однак на великих таблицях вирішальне значення має розмір правого розміру. Причина полягає в тому, що оцінки пам'яті базуватимуться на припущенні, що кожне значення буде заповнене на 50%. Отже, якщо у вас є varchar (128), кожне значення очікує, що воно займе 64 байти, незалежно від фактичних даних, тому дозволи на пам'ять становитимуть 64b * кількість рядків. Якщо всі значення становитимуть 32 символи або менше, то, мабуть, кращий вибір варчар (64) або навіть варчар (32). Якщо великий відсоток значень близький до або біля межі, ви навіть можете сперечатися за те, щоб Char зняв з нього нестабільність.

Що стосується переваг обмеження довжини рядків при потужностях 2, я не думаю, що на сьогоднішньому апаратному забезпеченні хтось може продемонструвати явні переваги.