Нет сомнений в том, что по возможности следует избегать значений NULL, поскольку из-за проблем они могут создавать некоторые проблемы с индексацией и синтаксисом запросов.
Из-за проблем, которые могут возникнуть в NULL, был сделан шаг к тому, чтобы прекратить их использование. Однако, как и большинство таких движений, он вышел из-под контроля, и некоторые люди фанатично настаивают на том, чтобы в базе данных никогда не использовались значения NULL. Я пробыл в этом лагере много лет, пока не нашел его слишком усердным.
Ответ где-то посередине. По возможности следует избегать NULL, но для их хранения действительно есть веские коммерческие причины.
Часто вам нужно хранить необязательное числовое значение, и многие люди говорят вам, чтобы вы просто хранили ноль, чтобы указать «нет значения», но это еще худший антипаттерн хранения магического значения, которое действительно означает что-то другое. Что если тогда вы не можете использовать ноль для одного поля, потому что ноль также считается значимым значением, или потому что это значение используется как кратное делителя, поэтому вам нужно использовать какое-то другое магическое значение (-1? ) для этого поля только в этом случае, и теперь у вас проблема хуже, потому что все ваши необязательные числовые поля теперь ведут себя по-разному. Oye.
Даты являются еще более убедительным кандидатом на пустые поля. Стандартное значение «без значения», которое люди используют в .NET, - это неназначенное значение DateTime по умолчанию, то есть DateTime.MinValue или, более конкретно, 1 января 0001 года. Однако вы не можете записать это магическое значение в базу данных SQL, поскольку минимальное значение по умолчанию для поле DATETIME для SQL Server - 1 января 1973 года. Теперь у вас должно быть что-то, что проверяет, правильно ли вы переводите эти значения, когда они записываются и считываются из базы данных, и вы должны иметь защитное кодирование повсюду, которое проверяет для того, чтобы ваши поля даты были меньше, чем SqlDateTime.MinValue, вместо того, чтобы просто проверить, равны ли они DateTime.MinValue. Double Oye.
Я предпочитаю иметь дело со значениями такими, какие они есть на самом деле, а не создавать множество искусственных конструкций, чтобы скрыть истинное значение и использование поля. Если у поля вполне может не быть значения, сделайте его обнуляемым и сделайте его обнуляемым также и в ваших объектах приложения (если ваш язык поддерживает такую вещь). Затем, всякий раз, когда вы используете это поле, вы должны подумать, что следует делать в случае, когда оно равно NULL, но на самом деле это хорошая вещь. Обычно я против того, чтобы заставлять разработчиков тратить мозги на ненужную сложность кода, но это потому, что это отвлекает внимание от решаемой бизнес-проблемы; однако в этом случае отсутствие стоимости является частью настоящей бизнес-проблемы и должно быть продумано. Если вы просто используете эти значения по умолчанию, то разработчик, пишущий формулу или алгоритм, с меньшей вероятностью будет продумывать те граничные условия, в которых значения отсутствуют, и может даже не осознавать, что в то время существует вероятность того, что эти значения отсутствуют .