Стандартное использование 'Z' вместо 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" совершенно нормально (вот для чего он существует). Единственным недостатком является то, что код, который потребляет данные, должен быть написан для проверки на наличие нулей. Я всегда так делал.

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

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

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

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

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

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

(кстати, я бы не особенно хотел работать с подрядчиком, который говорит вам в лицо, что они и другие "продвинутые" DBAs намного более осведомлены и лучше вас.)

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

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

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

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

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

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

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

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

• пустая строка NULL
• пустая строка требует хранения 2 байта + смещение чтения
• NULL использует нулевое растровое изображение = быстрее
• идентичность не всегда начинается с 1 (Зачем тратить половину вашего диапазона?)

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

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

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