BelyКласть в почтовый ящик.
Абсолютно верно. Теперь вернись к своему примеру и скажи, почему Ване - класть в почтовый ящик, а директору - нести в собственные руки?

BelyПотому что если в доме 5 магазинов, то отнести надо в правильный магазин.
Далеко не всегда. Довольно часто отдается вахтеру/охраннику/прочему человеку на проходной, а дальше уже люди "из офисов" у него забирают.

BelyВ случае с коммуналкой - там либо один почтовый ящик на всех и жильцы сами разбираются кому чего, либо несколько ящиков с фамилиями и тогда опускать надо по фамилии.
Еще лучше. Так фамилия / название магазина - это таки часть адреса или нет?

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

Cane Cat FisherИ все получится.
Ну если под "все" понимать "геморрой", то "все" и получится. Весь мир спокойно работает со skip-level hierarchies, а нам обязательно нужно придумать квадратные колеса...

Cane Cat FisherА чем они плохи?
Тем, что про них надо постоянно помнить и постоянно исключать "откуда не надо". Это трудоемко и ненадежно; можно быть уверенным, что ошибки "есть и будут вноситься", если конечно модуль мало-мальски нетривиальный.

Единственный известный мне случай, в котором их применение бывает удачно - хранилища данных, заточенные под визуальную отчетность.

Cane Cat FisherЕсли через список районов нужно добраться до любого города, то логично, если города, не относящиеся ни к какому району, будут сидеть за пунктом справочника "города областного подчинения". Или лучше, чтобы они просто перемешались с районами?
Вы попадаете точно в одну из моих любимых тем: "Одной из наиболее частых ошибок, совершаемых разработчиками, является попытка установить взаимно однозначное соответствие между представлением данных в клиентском интерфейсе и структурой данных на сервере".

Cane Cat FisherНо ведь это не значит, что если представление данных в БД совпало с одной из форм его представлений клиенту, то такое решение обязательно ошибочно.
Не значит. Это значит, что Ваш аргумент не относится к делу (поскольку Ваш аргумент ссылается на интерфейс, а тот в общем случае не определяет структуру данных).

Cane Cat FisherНапример, я согласен, что при печати адреса ул."нет улицы" некрасиво. Но в то же время при вводе адреса в форму понятие "нет улицы" хорошо бы видеть явно...
Конкретно с этим "хорошо бы" я скорее не соглашусь, но это не так важно; разумеется, где-то специально нужно помнить и о "null с последствиями". Однако, сугубо практически - иметь дело с потребностью второго типа намного приятнее. Почему именно так - не готов уверенно судить; это просто "статистика по моему опыту".

Cane Cat Fisherok, я допускаю, что хранение информации в БД без фиктивных сущностей правильнее, чем с ними. Но приведите пожалуйста структуру данных правильного хранения адресной информации. Я хочу понять, какой же должен быть слой логики, чтобы привести ее в вид, удобный для пользователя - как для ввода, так и для вывода. И не забудем выборки по адресным условиям.
Единственно правильной структуры все же не существует - зависит от. Скажем, приведенная схема с контейнерами вполне хороша с точки зрения "на ходу учесть любой адрес, с которым только придется столкнуться".

Для задачи топикстартера, думаю, оптимальной будет одна таблица с кучей полей, большинство из которых допускают null. Поля соответствуют разным возможным фрагментам адреса, включая все названные здесь "километры", "микрорайоны" и прочие извращения; при этом не следует жадничать и пытаться упихать в одно поле несколько разных смыслов (типа - если так, то это номер дома, а если эдак, то это номер километра МКАД; лучше завести два поля. Возможно, даже номер дома-владения и квартиры-офиса лучше делать разными полями, тут уже надо думать). С помощью check constraint-ов описываются правила заполнения (скажем, "если задан номер квартиры, то должен быть задан и номер дома" или "если задан микрорайон, то улица уже не задается").

Фактически это - жестко заданный вариант тех же контейнеров, но статическая линейная структура таблицы позволяет очень легко работать с этими данными: формировать адрес, искать такие же/близкие адреса, делать поиск по части адреса, реализовывать любой интерфейс ввода и обмен с источниками. Недостатком можно назвать тормознутость некоторых операций в существенно иерархическом интерфейсе (скажем, если мы, стоя на "улице", разворачиваем список домов), но это лечится дополнительными индексами или materialized view.