Стандартное использование Z вместо NULL для представления отсутствующих данных?

Увольняйте подрядчика.

Ладно, серьезно, это не стандартная практика. Это можно увидеть просто потому, что все СУБД, с которыми я когда-либо работал, реализуют NULL, логику для NULL, учитывают NULL во внешних ключах, имеют другое поведение для NULL в COUNT и т. Д. И т. Д.

На самом деле я бы сказал, что использование «Z» или любого другого заполнителя еще хуже. Вам по-прежнему требуется код для проверки "Z". Но вам также необходимо задокументировать, что «Z» не означает «Z», это означает что-то еще. И вы должны убедиться, что такая документация прочитана. И что тогда произойдет, если Z когда-нибудь станет действительной частью данных? (Например, поле для инициала?)

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

РЕДАКТИРОВАТЬ

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

Я использовал это, например, для данных с привязкой к дате. Если данные действительны между датой начала и датой окончания, код можно упростить, не имея значений NULL. Вместо этого НУЛЕВАЯ дата начала может быть заменена на «01 января 1900 года», а НУЛЕВАЯ дата окончания может быть заменена на «31 декабря 2079 года».

Это все еще может изменить поведение по сравнению с ожидаемым, поэтому его следует использовать с осторожностью:

• WHERE end-date IS NULL больше не предоставляют данные, которые все еще действительны
• Вы только что создали свою собственную ошибку тысячелетия
• и т.п.

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

Тем не менее, уволите подрядчика.

Это одно из самых странных мнений, которые я когда-либо слышал. Использование магического значения для представления «нет данных», а не NULL, означает, что каждый фрагмент кода, который у вас есть, должен будет обрабатывать результаты, чтобы учесть / отбросить значения «без данных» / «Z».

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

select * from mytable where name = 'bob';
select * from mytable where name != 'bob';

Если name когда-либо имеет значение NULL, очевидно, что он не будет отображаться в результатах первого запроса. Что еще более важно, это не будет отображаться и во вторых результатах запроса. NULL не соответствует ничему, кроме явного поиска NULL, как в:

select * from mytable where name is NULL;

А что произойдет, если в данных может быть допустимое значение Z? Допустим, вы храните чей-то средний инициал? Можно ли отнести Закари Зонкаса к тем людям, у которых нет инициалов в середине? Или ваш подрядчик придумал бы еще одно волшебное средство, чтобы справиться с этим?

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

Если домен допускает пропущенные значения, тогда использование NULL для представления «undefined» совершенно нормально (для чего он нужен). Единственным недостатком является то, что код, потребляющий данные, должен быть написан для проверки наличия NULL. Я всегда так поступал.

Я никогда не слышал (и не видел на практике) использования буквы «Z» для представления недостающих данных. Что касается «подрядчик называет это« стандартной практикой »среди администраторов баз данных», может ли он предоставить некоторые доказательства этого утверждения? Как упоминал @Dems, вам также необходимо задокументировать, что «Z» не означает «Z»: как насчет столбца MiddleInitial?

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

Даже если вам каким-то образом удастся объяснить всем своим нынешним и будущим разработчикам и администраторам баз данных про "Z" вместо NULL, и даже если они все кодируют идеально, вы все равно запутаете оптимизатор, потому что он не будет знать, что вы это все придумали. .

Использование специального значения для представления NULL (которое уже является специальным значением для представления NULL) приведет к перекосу данных. например 1 января 1900 г. произошло так много всего, что это лишит оптимизатора возможности понять тот фактический диапазон дат, который действительно имеет отношение к вашему приложению.

Это похоже на решение менеджера: «Ношение галстука плохо сказывается на производительности, поэтому мы все будем носить малярный скотч на шее. Проблема решена».

Я никогда не слышал о широко распространенном использовании 'Z' вместо NULL.

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

 +=================================+
 |  FavoriteLetters                |
 +=================================+
 |  Person      |  FavoriteLetter  |
 +--------------+------------------+
 |  'Anna'      |  'A'             |
 |  'Bob'       |  'B'             |
 |  'Claire'    |  'C'             |
 |  'Zaphod'    |  'Z'             |
 +---------------------------------+

Как ваш подрядчик интерпретирует данные из последней строки?

Возможно, он выберет другое «магическое значение» в этой таблице, чтобы избежать столкновения с реальными данными 'Z'? Это означает, что вам нужно запомнить несколько магических значений, а также то, какое из них используется, где ... как это лучше, чем иметь только один магический токен NULL и помнить о трехзначных логических правилах (и подводных камнях), которые связаны с ним ? NULL по крайней мере стандартизирован, в отличие от 'Z' вашего подрядчика.

Мне тоже не очень нравится NULL, но бездумная замена его действительным значением (или, что еще хуже, несколькими действительными значениями) везде почти определенно хуже, чем NULL.

Позвольте мне повторить здесь мой вышеупомянутый комментарий для большей наглядности: если вы хотите прочитать что-то серьезное и обоснованное людьми, которые против NULL, я бы порекомендовал короткую статью " Как обрабатывать отсутствующую информацию без использования NULL " < / a> (ссылки на PDF-файл с домашней страницы Третьего манифеста).

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

Я не слышал, чтобы Z назывался "стандартной практикой" в качестве значения-заполнителя вместо нулей, но я ожидаю, что ваш подрядчик имеет в виду концепцию контрольных значений в целом, которые иногда используются в базе данных дизайн. Однако гораздо более распространенный и гибкий способ избежать нулевых значений без использования «фиктивных» данных - это просто их спроектировать. Разбейте таблицу таким образом, чтобы каждый тип фактов записывался в таблицу, не имеющую «лишних», неопределенных атрибутов.

В ответ на комментарии подрядчиков

• Пустая строка ‹> NULL
• Пустая строка требует хранения 2 байта + чтение смещения
• NULL использует нулевое растровое изображение = быстрее
• ИДЕНТИЧНОСТЬ не всегда начинается с 1 (зачем тратить половину диапазона?)

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

Хотя я никогда не видел «Z» как магическое значение для представления null, я видел, что «X» используется для обозначения поля, которое не было заполнено. Тем не менее, я видел это только в одном месте, и мой интерфейс чтобы это была не база данных, а XML-файл… поэтому я не был бы готов использовать это в качестве аргумента в качестве общепринятой практики.

Обратите внимание, что мы должны обрабатывать «X» специально, и, как упомянул Демс, мы должны задокументировать его, и людей это сбило с толку. В нашу защиту это навязывает нам внешний поставщик, а не то, что мы сами придумали!