Данная схема не включает в себя:
-договоров контрагентов
-банковские счета контрагентов
-дневник взаимоотношений с клиентом

Немного о сути задачи:
-структура справочника контрагентов для БД складского учета/торговли
-контрагент может быть как ЮЛ так и ФЛ
-жесткие требования к введенному адресу контрагента (по этим данным контора отчитывается в гос. органы)

Немного о реализации
TDB_AGENTS - т.н. общие реквизиты для контрагентов
TDB_AGENTUL - сведения исключительно по юрикам
TDB_AGENTFL - сведения исключительно по физикам
TDB_NAMEM,TDB_NAMEL,TDB_NAMEF - справочники фамилий имен отчетсв
TDB_AGENTSADDR - адреса контрагентов, предусмотрена периодичность действия адресов (CACTUAL - DATE)
RDB_ADDRTYPES - классификатор типов адресов (фактический, юридический и т.д.) пользователю не доступен для редактирования
TDB_INDEXY,TDB_STRANY,TDB_REGIONY,TDB_NASPUNKTY,TDB_ULIZY - справочники для хранения улиц, стран, городов.... (обдумывается вариант импорта из КЛАДР)
TDB_AGENTSCONT - контактные лица контрагента (тут вариант либо это кто то из офиса юр.лица либо это те лица с которыми можно контактировать в случае если физика дома нет)
TDB_AGENTSINFO - контактные телефоны, аськи, мейлы и прочее
RDB_INFOTYPES - типы контактной информации (телефоны, мейлы аськи и т.п.), пользователю на редактирование не доступен
TDB_AGENTSDOCS - удостоверяющие документы контрагента, (паспорта, доверенности и прочее), периодичен (либо действует С ... ПО... , либо действует С... пока не перекроют другим документом)
RDB_DOCTYPES - типы документов (паспорт, доверенность, справка об освобождении и т.п.) пользователю не доступен.

Жду пинков и зуботычен от гуру!
Заранее благодарен за любую критику

На счет фамилий имен и отчеств тоже спорный момент но я принял решение исходи из того, что имеется в текущей базе данных, сделал обычный:
SELECT COUNT(*),ФАМИЛИЯ FROM КОНТРАГЕНТЫ GROUP BY ФАМИЛИЯ

Результат в некоторых случаях зашкалил за 10 исходя из этого я и принял такое решение
На счет именования колонок учту, спасибо.

Меня еще очень сильно терзает вопрос с периодичностью наименований контрагентов и всяких там ИНН/КПП

ModelR1. Если планируете КЛАДР,
то логично разделить TDB_AGENTSADDR на собственно адресное пространство (до улиц), задаваемое КЛАДР и связь элемента адресного пространства с контрагентом.
КЛАДР использовать не планируется, требований к точности ифнормации хранимой в справочниках касательно улиц, городов и т.п. не предъявляется, главное чтобы можно было отличить индекс от страны и сугубо в таком виде передать информацию эту куда следует.

ModelR
2.Реквизиты физических/юридических лиц могут меняться со временем.

Вот исходя из этого боюсь погрязнуть в реализации *правильной* БД поскольку уже образуется минимум 2 таблички
Тип реквизита - Значение - Дата
от типа FK на Типы значений (внутри ИНН,КПП,Полное наименование,Фамилия,Имя,Отчество и т.п.)
Что достаточно сильно может усложнить клиентское приложение.

ModelR
И про КЛАДР и про физиков-юриков здесь много обсуждалось. Поищите, может какие-то вещи пригодятся.
Спасибо, уже двигаюсь в этом направлении