Dindilin,
Интересно, что за мода такая?
Тут в параллельной ветке Нелепый вопрос для опытных профессионалов
тоже придумали сущность "адрес" и хотят что-то делать с ее id.
Чем принципиально отличаются "типы" адресов сотрудников и фирм-клиентов?

Храните id_street, numer (дома, надо полагать?) и kvartira прямо в таблицах с атрибутами сотрудников и клиентов.

Нарисовання вами структура смотрится красиво, но не учитывает кучу нюансов территориального-административного деления даже внутри РФ (см. КЛАДР), не говоря уже о мировых масштабах.

Кроме справочника улиц, я бы сделал справочник населенных пунктов и справочник территориальных образований, соответствующе справочники типов н.п., тер. образований, ну и улиц, если уж так приспичило
Связи подчиненности между территориальными образованиями - ссылками на id родительских объектов (колонка id_ParentRegion).
Ну, страны можно выделить в отдельную таблицу, если глобальный масштаб так необходим.

С такой структурой тоже не просто работать, но она, хотя бы, не требует переделки при появлении нового уровня территориального деления.

Dindilin,
Только сейчас разглядел: а telephon зачем в таблице "адрес"?!!

Dindilinbaracs, отредактировал схему
Отредактировали ее, таки, вы
Я не предлагал справочник наименований (я правильно понял назначение таблицы Socr_base?), ну и бог с ним.

"Мишку мучает вопрос:" (c)
зачем же все-таки нужна таблица "adres"?
Почему нельзя street_id, nomer и kv вставить прямо в таблицы firm и sotrudnik?

Кстати, колонки nomer и kv делайте символьными. Уж номер дома-то точно: бывают литеры, корпуса, строения...
Правда, корпуса и строения лучше вынести в отдельные колонки...

tanglirУж номер дома-то точно А ещё бывают, например, такие адреса: "ул. Уличная, дом 13, кв.666, комната 1 ". Как он в Вашу схему впишется?
Ага, давайте еще койко-место укажем

SERG1257Зачем нужен адрес - для почты? тогда идите на почту, берите их базу, подгоняйте под их требования
Для отчетов в налоговую - тут кладр рулит
А налоговая ведет КЛАДР разве не совместно с почтовой службой?
SERG1257Смысл выделения в отдельную таблицу адресов иногда есть, но в каждом случае решение надо принимать самостоятельно.
Само собой.

DindilinА ведь одна и таже улица может встречатся в разных городах
г. Самара, ул. Строителей
г. Сызрань, ул. Строителей
тогда получается что запись в улицах, Строителей будет не одна а несколько? а если такая улица, будет в 10 городах....
Да. Это разные объекты с одинаковым наименованием.
Сколько в бывших странах развитого социализма улиц Ленина, даже старшно подумать

Вопрос в том, на сколько важен этот факт для решаемой вами задачи.
Если, например, надо хранить историю переименований, то важен.

buhBotТо, что обработка такой структуры в основном только рекурсией - нас это не волнует (это волнует программистов).
Чтоб я так жил!

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

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

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

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

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

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

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

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