Все, кто занимается технологиями, должно быть, работали с NULL-фобами из команды баз данных. В настоящее время я работаю в команде, у которой есть рекомендации по архитектуре данных, изложенные одним из них. В руководящих принципах говорится что-то вроде: НЕ ДОЛЖЕН, я повторяю, НЕ делать столбцы NULLable.

Каковы аргументы в пользу ненависти к значениям NULL в базах данных?

NULL лучше всего описывается как нетипизированное и неизвестное значение, которое нельзя даже приравнять к другому NULL. Таким образом, мы не можем применять такие предикаты в предложении SQL WHERE: NULL = NULL, или NULL ‹› NULL, или 0 = NULL. Столбец, допускающий значение NULL, может указывать на некоторые недостатки, описанные ниже, или приводить к ним.

Необходима дальнейшая нормализация

Рассмотрим эту таблицу.

Последние два столбца должны иметь значение NULL, потому что CustomerId 112 и, возможно, многие другие клиенты не указали контактную информацию. Оглядываясь назад, столбцы ContactMethod и Contact являются кандидатами на дальнейшую нормализацию. Нормализация избавит от необходимости использовать NULL. Запись будет добавлена ​​в дочернюю таблицу ContactInfo, только если доступна какая-либо контактная информация.

В этом случае разрешение NULL в таблице Customer выявляет недостаток дизайна, известный как аномалия вставки. Объявление двух последних столбцов равными NULL было просто быстрым решением, позволяющим скрыть неправильную нормализацию.

Бремя трехзначной логики

Разработчики приложений обычно пишут код вокруг двух логических значений: TRUE или FALSE. Все управляющие структуры в языках программирования — if-else, while, for, switch — работают на основе этой логики с двумя значениями. Но когда им приходится писать код базы данных, им приходится учитывать дополнительное значение NULL. Бремя трехзначной логики также увеличивает вероятность ошибок.

Интерпретации различаются

Некоторые базы данных обрабатывают пустые строки как NULL. Я знаю, что Oracle работала таким образом, по крайней мере, в 9i и 10g. Некоторые другие базы данных и приложения обрабатывают пустые строки как просто пустые строки (представленные знаком ‘’), а значения NULL — как просто значения NULL или неизвестные значения. Я знаю, что некоторые инструменты ETL ведут себя таким образом. Это бремя для разработки приложений. Это создает ситуации зависимости при миграции приложений.

Заботы без схемы

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

Каковы решения для борьбы с NULL?

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

Мое неизвестное значение даты рождения будет выглядеть как 1900–01–01. Или 2999–01–01. Теперь приложения должны не забывать кодировать около 1900–01–01. Это не делает ситуацию лучше. На самом деле это делает его хуже. Если бы это было просто NULL, любой новичок в команде знает, что с этим нужно справиться. Теперь кто-то должен сказать новичку: «Эй, у нас в базе данных есть странная дата, о которой вы должны знать, прежде чем писать запрос».

Есть ли другие решения?

Одно из решений — быть умеренным, а не пуристом. Подводить баланс.

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

Да здравствует НУЛЬ!