1. Вы в курсе, что id=0 неприменим при джойне?
явно видно, что вы, двое, разговариваете на разных языках или пользуетесь разными терминами.
2. Нет записей "Нет значения". Таковыми могут быть только поля. И как мне делать отбор по ней? Считать, что запись, означающая "нет значения", всегда имеет id=1? А если там есть еще логическое разделение и таковых записей может быть несколько?
насчет "логического разделения" это уже перебор. WildSery ведет речь о том, что null в FK считается "нехорошим", и заменяется на дополнительную запись в справочнике с идентификатором 0, -1 и т.д. В результате наоборот, пропадает необходимость в outer join если требуется вытащить заказы "неизвестных клиентов" или что-то вроде.
Короче, см. "Введение в системы баз данных" Дейта, глава 19 "Отсутствующая информация", конкретно со страницы 749 в восьмом издании.
"...
Наконец, следует отметить, что "необходимости" разрешить присутствие неопределенных значений (NULL) во внешних ключах вполне можно избежать за счет соответствующего проектирования базы данных [19.19]. Еще раз обратимся к примеру с отделами и сотрудниками. Возможна ситуация, когда некоторые сотрудники действительно не относятся ни к одному из отделов. Но тогда, как уже предполагалось в конце предыдущего раздела, логичнее было бы не включать атрибут номера отдела DEPT# в переменную отношения EMP, а создать отдельную переменную отношения (скажем) ED с атрибутами EMP# и DELPT#, предназначенную для представления того факта, что указанный сотрудник работает в данном отделе..."
и дальше, в разделе 19.5
"Таким образом, внешнее соединение предназначено для решения весьма важной проблемы, заключающейся в потере информации при внутреннем соединени. Некоторые авторы высказывают мнение, что система должна обеспечивать прямую и явную поддержку внешних соединений, вместо того чтобы требовать от пользователя при формировании запроса прибегать к различным ухищрениям для достижения желаемого результата. В частности, в [6.2] приведено мнение о том, что внешние соединения должны быть неотъемлемой частью реляционной модели. Тем не менее, в этой книге автор не поддерживает эту позицию, в частности, по приведенным ниже причинам:
- Прежде всего, безусловно, операция внешнего соединения использует неопределенные значения (NULL), а автор настоящей книги всегда выступает против этого по целому ряду описанных ранее основательных причин.
- ...
- Наконец, уже было высказано мнение о том, что
атрибуты со значениями в виде отношений представляют собой альтернативный подход, позволяющий радикально устранить все эти проблемы. Такой подход исключает необходимость использования неопределенных значений (NULL) и операций внешнего соединения и в целом, по мнению автора, представляет собой более изящное решение (не гноворя уже о том, что это - реляционное решение, которое не приводит к нарушению реляционной модели. ..."
Короче, читайте папу Дейта....
Конечно, ему можно следовать или нет, но прочитать эту самую главу нужно обязательно, пусть это даже будет единственная глава из книги.
Тьфу, извините, надо было и дальше поцитировать. Раздел 19.6
"Как показано выше, введение неопределенных значений (NULL) приводит к разрушению реляционной модели, которая великолепно обходилась без них в течение десяти лет с момента ее создания в 1969 году и вплоть до введения этих значений в 1979 году.
Теперь предположим, как показано в разделе 19.4, что понятие
неопределенных значений в контексте представления отсутствующей информации заменено понятием
специальных значений. Следует отметить, что в реальном мире мы обычно пользуемся именно специальными значениями. Например, специальное значение "?" используется для обозначения количества рабочих часов для некоторого сотрудника, если его фактическое значение по какой-либо причине неизвестно. Таким образом, общая идея заключается в том, чтобы просто применять подходящее специальное значение, отличное от всех обычных значений атрибута, во всех тех случаях, когда обычное значение не может использоваться. Обратите внимание, что это специальное значение обязательно должно принадлежать к соответствующему типу.
..."