Чи порожні стовпці займають місце в таблиці?

У мене є таблиця, яка вміщує в собі дуже основну інформацію. Просто заголовок та кілька полів дати. Існує одне поле під назвою коментарі, яке є varchar (4000) Більшу частину часу ми залишаємо його порожнім, але іноді тут буде вводитися велика кількість даних. Це справді поганий дизайн? Або це просто трохи неефективно?

Я б припустив, що краще створити окрему таблицю для цього стовпця.

Примітка: це сервер sql 2008

Для отримання більш передбачуваної продуктивності (і щоб уникнути великої різниці рядків на сторінці), я схиляюся до зберігання цих даних у відповідній таблиці - особливо, якщо вона заповнена лише невеликим відсотком часу, і особливо, якщо вона отримана лише в деякі запити. Рядки, де це значення, дійсно NULLсприяють простору накладних витрат, але це мінімально. Більш важливим буде те, як одна сторінка може вміщувати лише два ряди, а наступна сторінка може вміщувати 500 рядків - це може дійсно вплинути на статистику, і ви, можливо, краще розділити це, щоб воно зберігалося окремо і не впливало на всі ваші операції на основна таблиця.

Займає мінімальний простір, коли не використовується

• один біт у растровій карти NULL
• два байти по довжині (яка буде нульовою, коли NULL)

Накладні витрати мінімальні, і оптимізація буде передчасною.

Поки ви не дізнаєтесь, що у вас є проблема, просто зберігайте її в одній таблиці. Ви порушуєте KISS, вводячи зовнішні з'єднання та додаючи накладні дані в запитах даних.

Дивіться /programming/3793022/how-to-come-to-limits-of-8060-bytes-per-row-and-8000-per-varchar-nvarchar-valu/3793265#3793265 для отримання додаткових відомостей

Я думаю, що окрема таблиця буде краще покращити щільність сторінки та зменшити фрагментацію, особливо якщо ви не завжди заповнюєте це поле.

• Сторінка даних містить близько 8000 байт
• У вас є кілька рядків із значенням 100 байт, а деякі рядки - понад 4000 байтів
• Ці довгі рядки опиняться на самій сторінці, а решта сторінки - це "витрачений" простір, який займає ваша БД, але, ймовірно, ніколи не зберігатиме дані
• Якщо ви додасте дані в це довге поле для запису на сторінці, що знаходиться в основному на повній, це, ймовірно, перекриє сторінку та призведе до вказівника на сторінку з рештою запису

Усі ці порожні сторінки та покажчики призводять до низької продуктивності. Нормалізуйте це поле, якщо можете.

Це питання виглядає дуже схоже: чи впливають зайві порожні стовпці на розмір таблиці sql?

Схоже, відповідь "так", вона займає місце, але існує алгоритм стиснення для стовпців з великою кількістю нульових значень.

Що стосується дизайну, я думаю, що мати зовнішній стіл, пов'язаний з цим, було б більш чистим дизайном. Наявність стовпця з частими нульовими значеннями ускладнює користувачів бази даних, оскільки вони можуть випадково використовувати нульове значення, якщо вони не обережні. Тому код, що використовує базу даних, повинен містити перевірку помилок, і звідти він просто стає некрасивим.

Вам буде добре - це вже стовпець varchar, тому він використовує простір лише тоді, коли містить дані. Якщо у вас було багато змінних стовпців фіксованого розміру, таких як int, у вас можуть виникнути проблеми використання місця.

Що стосується того, щоб помістити його в іншу таблицю, я б не переймався. Можна також переглянути варіанти varchar (max) та параметри введення / виходу рядків. Знову, напевно, передчасно.