Создание таблицы базы данных NULL, лучшие практики

Question

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

Следует ли переместить два поля в отдельную таблицу, создав две таблицы без значений NULL?

Объединение этих двух таблиц просто вернет результат, равный моей исходной таблице с NULL, так какой смысл в этом?

Кажется бессмысленным разделять их, но я читал немного о том, как избегать нулевых значений вместе в БД.

Любые мысли приветствуются.

Answer 1

1. Чисто теоретически, NULL должен означать «неизвестное значение». Итак, опять же, чисто теоретически, вы должны разрабатывать свои таблицы при нормализации, чтобы вам не нужно было заполнять значения NULL, чтобы означать «неприменимо для этой строки». Однако этот момент практически не имеет никакого отношения к практическим соображениям (дизайн, производительность или удобочитаемость запросов).

2. Практически, есть некоторые соображения производительности. Вы должны нормализовать очень разреженные данные в следующих случаях:

   • Сокращение таблицы имеет материальную выгоду (как для ввода-вывода, так и для пространства). Значения NULL занимают место, и чем шире строки, тем хуже производительность. Это особенно верно, когда таблица имеет много строк и таких столбцов много. Для таблицы меньшего размера, имеющей только 2 таких столбца, реализованные преимущества могут не стоить того, чтобы иметь дополнительное соединение.

   • В ваших запросах есть соответствующий столбец в предложении WHERE. IIRC, запрос к столбцу со значительным нулевым значением довольно неэффективен.

   • С другой стороны, в определенный момент наличие дополнительных объединений в запросе может снизить производительность оптимизатора (по крайней мере, это происходит в Sybase, когда в ваших объединениях имеется более 10 таблиц) - от использования ресурсов ЦП при запуске оптимизатора чтобы действительно запутать оптимизатор, чтобы выбрать очень плохой план). Решение состоит в том, чтобы избежать слишком большого количества таблиц из-за нормализации (например, не пытайтесь разделить 2 столбца в отдельную таблицу) или форсировать план запроса. Последний явно Бад Джуджу.

Answer 2

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

По правде говоря, некоторые данные просто не известны на момент вставки записи.Ничто не может заменить ноль.

Теперь в вашем случае, если вам нужно разбить две таблицы на две, на ширину таблиц и на частоту, с которой вы будете запрашивать эти обнуляемые столбцы.Я вряд ли перенесу столбец среднего имени в другую таблицу, хотя у меня было много нулей, потому что он всегда запрашивается с другой информацией в базовой таблице.Я также вряд ли перенесу столбец конечной даты.Но если столбцы - это вещи, которые хорошо знать, но обычно их не запрашивают всякий раз, когда вы запрашиваете базовые данные (например, день рождения, цвет волос и т. Д.), Тогда может подойти отдельная таблица только для записей, содержащих данные.Помните, однако, что когда вы запрашиваете, используете ли вы внутреннее соединение, вы удаляете все записи, которые не имеют значения во второй таблице.Если бы я обычно хотел, чтобы все записи (как со вторым именем, я редко запрашиваю людей, имеющих второе имя «Мэри»), то я склонен хранить их в одной таблице, если таблица не становится очень широкой, и я необычно не хотят запрашивать эту информацию.

Answer 3

Как следует из комментария dportas, полезно знать, что означает значение null в определенном поле - не то, что оно означает в теории, но что это означает в ваших данных .

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

Мнение: мое эмпирическое правило таково, что пустые поля хороши, но не должны выполнять несколько задач

Answer 4

Пустые значения приводят к неправильным и противоречивым результатам в запросах и обычно увеличивают сложность кода из-за специальной обработки, необходимой в коде, который должен их обрабатывать. По этим причинам обычно имеет смысл избегать или минимизировать пустые значения в ваших проектах баз данных. Вам также не нужно использовать пустые значения в запросах - хотя, к сожалению, SQL делает их очень трудными для избежания. Однако, не используя пустые значения в базовых таблицах, вы обеспечите более точное отражение вашей модели данных в реальности и дадите пользователям базы данных больший контроль над тем, как они хотят использовать нулевые значения.