SQL Server - недостатки производительности / размера пустых столбцов

Question

Я работаю над дизайном таблицы, который может включать много значений NULL примерно в 10 полях, возможно, в 75% случаев поля будут неиспользованы.

Я только что сгенерировал некоторые фальшивые данные (миллион записей) и не чувствовал никакого влияния на SQL Server 2005. Разница в размере была в КБ. Производительность - без ощутимой разницы после добавления индекса в 3 необнуляемых столбца.

Я знаю, что в SQL Server 2008 есть функция разреженных столбцов (которая, как я предполагаю, будет использоваться в следующей таблице пользовательских данных SharePoint). Я хочу, чтобы мой код работал в 2005 году. Но существует множество значений NULL в структуре текущей таблицы пользовательских данных SharePoint. Так что, если это достаточно хорошо для Microsoft ...

Какие-нибудь хорошие статьи, ссылки, технические документы о недостатках или болевые точки вокруг многих значений NULL в таблице SQL Server? Кто-нибудь знает, что происходит, когда вы масштабируете записи на 10 или 100 миллионов?

Answer 1

У меня никогда не было проблем с производительностью в нескольких нулевых столбцах, даже в базах данных размером в 100 с. Я полагаю, что вы можете столкнуться с проблемами, если вы запускаете индексы в этих полях, а затем используете нуль в запросе, но я лично не видел в этом проблемы. Опять же, я не создал таблицы базы данных, где каждое поле, кроме 3, могло быть обнуляемым.

С другой стороны, я вижу проблему с архитектурой, когда большая часть данных пуста. общая причина - а) неправильно нормализованная база данных или б) попытка разрешить пользователям размещать данные в конечной таблице, а не создавать отдельные таблицы для «построения» данных до фиксации в базе данных.

Вы должны определить лучшую архитектуру вашей базы данных.

Answer 2

Что я делаю в этой ситуации, которая очень распространена, это разбить данные на две таблицы:

• Обязательные данные
• Дополнительные данные

Например, я сейчас пишу сайт сообщества, и одна из таблиц, очевидно, будет таблицей пользователей. Я записываю большое количество информации о пользователях и собираю собираемые данные в две таблицы:

• Пользователи
• UserDetails

Таблица Users содержит основную информацию, которая мне будет нужна постоянно, такую ​​как имя пользователя, имя и информация о сеансе.

Таблица UserDetails содержит дополнительную информацию, которая мне не нужна, такую ​​как страница профиля, адрес электронной почты, пароль, адрес веб-сайта, дата рождения и т. Д.

Это известно как вертикальное разбиение .

Answer 3

Ну, NULL всегда немного странный в базах данных. Я не думаю, что это сильно влияет на производительность в вашем случае, но, конечно, вам придется работать со всеми значениями NULL отдельно.

Когда бы ни было возможно, я стараюсь использовать вместо этого значение по умолчанию, так что если у вас есть, например, какое-то значение идентификатора типа INT, вы можете использовать 0 или -1 в качестве индикатора «нет значения». Таким образом, вы можете избежать проверки значений (поле <0) и проверки NULL отдельно (поле IS NULL или IS NOT NULL). </p>

Марк

Answer 4

Проблемы, с которыми я сталкивался в прошлом, связаны с программными последствиями наличия значений NULL. Например, проблемы с клиентами или проблемы с отсутствием запросов, возвращающих данные, когда они не ожидаются, потому что там было нулевое значение.

Answer 5

Чем выше вероятность NULL в столбце, тем ближе к концу записи столбец должен находиться в таблице (к столбцу lat в таблице).
NULLS в конце строки не выделяются ни одного пробела, они определяются по NULL BITMAP, связанному с каждой записью (это 2 байта, каждый бит из которых говорит о (не) NULL-ness одного из значений столбца в записи ).

Теперь значения NULL не читаются из столбца, они считываются из растровых изображений NULL. При обнаружении NULL реальное значение пропускается

Разреженную функцию следует использовать с осторожностью, так как она вызывает накладные расходы во времени и пространстве для ненулевых значений Для повышения производительности вы можете использовать фильтруемое индексирование для ненулевой части столбца

Answer 6

Есть только один способ быть уверенным. Вставьте 100 миллионов записей, затем измерьте сквозную производительность.

Answer 7

Не составляйте таблицу с 75% неиспользуемых столбцов. Сделайте это со столбцами, которые вы собираетесь использовать все время, и изучите использование чего-то вроде EAV для других столбцов или поместите их в другую таблицу.