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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Marc

Answer 5

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

Answer 6

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

• Необходимые данные
• Факультативные данные

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

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

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

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

Это называется vertical partitioning.

Answer 7

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

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

Редкая особенности следует использовать с предостережениями, как это вызывает накладные расходы во время и пространстве для значений ненулевых Для выполнения, вы можете заниматься filtered indexing on non-null part of a column