по сабжу:

1. Нужна ссылка на родительскую запись. Необходимо для указания дочерних структур/торг. точек/точек доставки и пр.
2. Все реквизиты должны быть "на дату", т.е. если они меняются во времени, то нужно знать их значение на любую дату.
Даже название компании иногда полезно хранить исторически. Простое переименование может быть неприемлемо.

А вообще полезно для сабжа привлечь EAV. Часто возникают задачи добавить к карточке некий произвольный признак "прямо сейчас" и ЕАВ тут - самое то.

И тут он явно будет лишний, так как структуры более менее понятны.Да неужели ??????
Использование ЕАВ никак не мешает текущей структуре данных. Если текущ. структура устраивает, то ЕАВ просто будет пустой, но если вдруг появляется срочная необх. добавить новый признак, то это самое то.
Если это какой нить молодой CRM, то такая необходимость будет появляться часто.
При правильном использовании и неогромном основном справочнике, ЕАВ не создаст существенных тормозов. Но придаст гибкость.

ramkoМеня смущает производительность если таблицы с клиентами и их контрагентами объединить.
...
С Ув.
ВикторУ Вас это разные таблицы ???????! Если да, то это АДЪ.

Как ты сделаешь внешний ключ на две таблицы сразу, интересно?Как в 1С, бро. Там для этого применяют три поля:
тип ссылки/подтип ссылки/ID ссылки. :)

По сабжу: деление на 2 и более таблицы - дебилизм, ИМХО.
Клиент по сути ничем не отличается от контрагента. И он может быть одновременно и тем и другим.

Не берите пример с дебильных систем вроде Navision. Там две разных таблицы: галимое наследие из 80-х.
Хотя мож в новых версиях это исправили ? :) Но верится слабо.

fkthatLSVКак в 1С, бро. Там для этого применяют три поля:
тип ссылки/подтип ссылки/ID ссылки. :)
Пример 1С показателен, конечно. Эталон архитектуры.А чо там не так ? Имеет право на жизнь.
В некот. случаях это единственный способ кратко описать связь.

Н-р документ может быть создан на основании разных документов (их список может со временем расти).
Как описать родительскую связь иначе, чем Типдок/IDдок ?

внимательно слушаю.

fkthatLSVН-р документ может быть создан на основании разных документов (их список может со временем расти).
Как описать родительскую связь иначе, чем Типдок/IDдок ?

Да как-как, стандартно. Имеем базовый абстрактный тип сущности "документ" и производные типы сущностей, по разновидностям документов. Дальше используем стандартное либо "TPT" (если хотим больше гибкости), либо "TPH" отображение объектной модели на реляционную. И напоследок отношение M2M сущности "документ" на себя же.Много слов ниачомъ.
ООП головного мозга.

Как приведенный пример должен выглядеть в таблице подчиненных документов или к-л логе ?

Или пример: письмо-жалоба.
Может быть создано на основании 20-30 видов документов. Допустим "1 письмо - 1 основание".
Как должна выглядеть ссылка на документ (скорее всего в шапке письма) ?

fkthatLSVООП головного мозга.

При чем тут ООП. Понятие подтипов есть и в ERM и в IDEF 1x, которые с ООП никаким боком, если тебе эти аббревиатуры о чем-то говорят.Ты сначала дай ответ на вопрос, а том будешь сыпать умными аббревиатурами.