BelyВот стоит дом, номер у него 2. В доме находится несколько магазинов.
В какой нести почтальону письмо для директора Василия Петровича?
Вот стоит дом, номер у него 2, в нем коммунальная квартира, номер 28. В какую именно комнату нести почтальону письмо для Вани Жукова, 12-ти лет?

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.

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

Cane Cat FisherВот я и добиваюсь - где лежит этот признак (пропуска уровня дерева для объекта)? А все говорят, что он как-бы и не нужен...
Если он лежит, то лежит в справочнике городов. Но я также подозреваю, что он не нужен (допустим, в деревне Бобруевка торжественно построили первую улицу - уверены ли Вы, что успеете поменять соответствующий признак в справочнике раньше, чем к вашим клиентам/операторам придет человек с соответствующей пропиской в паспорте?)

Cane Cat FisherТогда встает вопрос проверки правильности (допустимости) адреса. Является ли адрес "г. Москва, кв.1" правильным? Как это определить?
Москва кв. 1 - неправильный, check должен его отсекать.

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