alexeyvgПри ограничении максимального уровня вложенности можно
Ниже вы про универсальность говорите...
alexeyvgПо моему, это проще, удобнее и универсальнее, чем ваша структура.
Проще и универсальнее, в данной ситуации, взаимоисключающие понятия.
То есть, рисовать структуру БД конечно проще. А вот, работать с ней...
alexeyvgКроме того, можно для каждого элемента держать полное собранное название
...
В многих СУБД, например, в MSSQL, это можно сделаеть одним апдэйтом в триггере.
Что выполнение триггера в MSSQL - тяжелая операция, изменение из триггера других таблиц (кроме той, с которой он связан) приводит к проблемам с блокировками и, наконец, триггеры весьма затрудняют понимание заложенной в БД бизнес-логики, вас видимо, тоже не волнует.

Попробую пояснить свое разбиение на таблицы.
Улица - основной объект адресации. И этих объектов будет больше всего.
_{Дома, квартиры и т.д. без крайней необходимости в базу пихать не стоит. Сейчас, даже в кризис, жилые дома и прочие строения появляются и исчезают как грибы. Уследить за этим "хозяйством" (т.е. поддерживать базу в актуальном состоянии) очень сложно.}
Наконец, с точки зрения привязки к карте (Чем черт не шутит? Вдруг понадобится?) - это линейный объект с присущими именно ему атрибутами.
_{Да, конечно, кроме улиц бывают еще кварталы, микрорайоны, населенные пункты вообще без улиц... Но подавляющее большинство населения обитает все-таки на улицах.}
Как быть с исключениями, надо решать в контексте поставленной задачи.

Населенные пункты я предложил вынести в отдельную таблицу т.к. это тоже отдельный класс объектов со своими атрибутами (важны они или нет в данной систме, не знаю), их тоже относительно много (смейтесь-смейтесь) и, с точки зрения картографа - это либо точечный (чаще), либо площадной объект.
_{Да есть огромные города, имеющие внутреннее территориальное деление и, с административной точки зрения, соответствующие регионам. Куда их удобнее "положить" тоже зависит от конкретной задачи.}

Наконец регионы . Это - территории, которые входят одна в другую как матрешки. Здесь не обойтись без поддержания иерархии.
Но регионов вместе со всем их "содержимым" (областями, землями, округами, районами, префектурами, сельсоветами и т.д.) на порядки меньше чем улиц и населенных пунктов. Соответственно, и ковыряться в этой иерархии будет, хоть и не на порядки, но легче (может быть, даже не придется искуственно ограничивать кол-во уровней вложенности ;-) ).
Ну, и опять таки, у регионов могут быть свои специфические атрибуты.

Отдельную таблицу стран можно рассматривать как каприз

baracsЗдесь не обойтись без поддержания иерархии.
Осспади! "Поддержания" - дело к вечеру

DindilinВот только как при запросе получить полный адрес из иерархической структуры.. Сверять до тех пор пока parentid не будет равен 0 ? =)
Почему бы и нет?
Пример функции на T-SQL, вычисляющей уровень товарной категории в классификаторе по коду категории (CategoryId - первичный ключ, ParentCategoryId - ссылка на первичный ключ родительской категории):

Сложность в другом: не все объекты, "вытащенные" таким образом из таблицы, могут понадобиться для формирования адреса.
Пример для Москвы.
Адрес: г. Москва, ул. Петровка, д. 38.
Что это - Центральный административный округ и муниципальный район Тверской, указывать не надо. Но, если использовать полную иерархию, они "вылезут".
Я вижу два пути:
1) просто отказаться от хранения информации по территориальному делению Москвы;
2) каким-то образом фильтровать "ненужные", при формировании адреса, территориальные образования.