> 2)Способом связи с лицом может быть почтовый адрес,
> и-мейл, телефон, URL, ...

Посмотрите внимательнее: телефон, e-mail, URL - на самом деле URI (с оговорками, которые пока несущественны). Похожие идентификаторы (не упоминаемые, правда, в соответствующем RFC (хотя могу и ошибаться, - давно не интересовался изменениями)) - телетайп, телекс, идентификаторы в частных сетях (Спринт etc) и прочие. Объединяет их то, что все они - суть _сетевые идентификаторы_.

Адрес (обычный географический) - не есть сетевой идентификатор. В общем случае (с оговорками) он может быть сопоставлен абсолютным координатам. Т. е. адрес - в первом приближении - просто удобная запись этих самых координат.

Прямой резон отделять сетевые идентификаторы от несетевых. ;)

> ИМХО наиболее рациональное решение - схема N+1

Imho разумное решение - это M каталогов, каждый из которых имеет собственную структуру данных и _однородное_ содержимое (степень однородности и правила группировки можно обсуждать).

> каталог объектов, супертип для этих подтипов

Я понимаю, о чем Вы говорите; претензии к терминологии. Это не каталог объектов. Это перечень сущностей (и, возможно, их атрибутов).

> Да логично выглядит

Нет, imho не логично. Мне непонятно, почему Вы стараетесь построить иерархию. Причем, по imho совершенно несущественным признакам.

Если уж Вам так необходимы типы, можно выделить голосовую (или - шире - mime-based) связь, - для целей, например, автоматизации обработки контактов.

Только это тоже нужно делать аккуратно: после принятия IPV6 (думаю, в течение ближайших пяти лет это произойдет) подход к сетевым идентификаторам хм... несколько изменится.

Еще: возьмите, например, google. У пользователя есть только один идентификатор имя@gmail.com, - а контакт может быть и голосовым, и IM (Google Talk), и почтовым. ;)

> Т.е. практически двухуровневой системы достаточно. Нет?

Imho невозможно дать однозначный ответ.

Иерархию вообще нужно использовать осторожно. Просто потому, что случаев явной однозначной иерархии на самом деле немного. Imho признаки уровней не должны быть произвольными, - они должны быть формальными (лучше - документированными, еще лучше - стандартными). Самое распространенное использование иерархических структур - классификация. Скажите, Вы знаете _хотя бы один_ классификатор, который был бы правильно построен? ;)

Возвращаясь к Вашему вопросу: любое проектирование - это всегда компромисс. Вы правы - два уровня иерархии удобны с точки зрения пользователя, - т. е. imho вполне себе можно использовать этот критерий, чтобы в подавляющем большинстве случаев ими и ограничиваться. При этом, разумеется, речь уже не идет о правильности построения такой иерархии. ;) Т. е. просто говорим: "Для практического применения достаточно использовать ..." и разрешаем бороться с созданным геморроем команде разработчиков, которая будет дальше развивать это проект. ;)

proposed amendment, если нечего сказать по существу, воздержитесь от комментариев: рискуете нарваться на оценку Вашего коэффициента умственного развития.

> взяли моду покупать безлимитный скай-линк и держать его по неделе
> в офисе одном,а потом переносить в другой дуря всех,что это
> стационарный телефон

Почему "дуря всех"?

В чем принципиальная разница между мобильной связью и стационарной? ;)

> телефон 123-12-45 живет на улице Петрова 25/03/06,а 234-56 на улице
> Иванова, а принадлежат они все клиенту Зябликову

Отличный пример того, как не следует делать (если, конечно, речь не идет о бд СЗТ). ;)

Не обладая легальным доступом к базе данных оператора, Вы не можете определенно сказать, что телефон 123-12-45 продолжает жить на улице Петрова. Продал владелец квартиру, новый владелец сменил номер телефона, - что, Вы и права собственности на недвижимость в Вашей базе данных регистрируете? ;))

Сеть СЗТ - это приватная сеть. А Вы в Вашей базе данных имитируете ее функционал. Imho абсолютно безосновательно.