Создание структуры БД: договор, физлица, юрлица. Как связать?

[Sundersson]

Подскажите новичку куда копать при создании структуры базы данных.
Есть три таблицы:
Договор
Клиенты физические лица
Клиенты юридические лица
Как создать связь, чтобы в договоре можно было выбирать или клиента физлицо или клиента юрлицо?
Если делать одну общую таблицу клиенты, содержащую информацию и о физлицах, и о юрлицах, то она получается громоздкая и много пустых полей.
Может есть другая, правильная реализация?

[p51x]

Сделайте таблицу связей ид, ид физ, ид юр

[Steelcraft]

Когда-то я много работал с реляционными базами данных и часто сталкивался с подобной ситуацией. Использовал нотацию IDEF1X и отношение категоризации. Попробуйте поискать в этом направлении.

[evg_m]

два поля ссылки
1 -- на юр. лица
2 -- на физ. лица
заполняется одно из...
можно в отдельной таблице
+ поле ссылка на договор

[Valick]

1 таблица Клиенты
id - идентификатор строки (идентификатор клиента)
type_id - тип клиента
(далее общие поля для клиентов не зависищие от типа)

2 таблица Тип клиента
id - идентификатор строки (идентификатор типа)
name - Наименование типа (юр лицо , физ лицо)
(далее поля специфические для типа клиентов)

3 таблица Юр клиенты
id - идентификатор строки
client_id - идентификатор клиента из таблицы Клиенты
(далее поля специфичные для юр клиентов)

4 таблица Физ клиенты
id - идентификатор строки
client_id - идентификатор клиента из таблицы Клиенты
(далее поля специфичные для физ клиентов)

5 таблица Договор
id - идентификатор строки
code - номер/код договора
client_id - идентификатор клиента

[Steelcraft]

Целесообразно еще в таблицах юр и физ ввести составной внешний ключ по полям id+type_id таблицы клиентов. Дополнительный контроль целостности (не позволит юрам ссылаться на записи для физов и наоборот).

Вообще такие ситуации очень хорошо разруливают всякие CASE для разработки баз данных (например, erwin). Помнится, он сразу генерировал скрипты для таблиц, представлений, индексов, ограничений, хранимых процедур CRUD etc. Избавляет от большого объема ручной работы и облегчает модификацию/сопровождение.

[Valick]

Сообщение от Steelcraft

Целесообразно еще в таблицах юр и физ ввести составной внешний ключ по полям id+type_id таблицы клиентов.

Не вижу выгоды. В таблице физиков все type_id будут например 1, в таблице юриков все type_id будут 2.

[Steelcraft]

Сообщение от Valick

В таблице физиков все type_id будут например 1, в таблице юриков все type_id будут 2.

Будут или должны быть? Это далеко не одно и то же.

Таблица физ ссылается на внешний ключ client_id из таблицы Клиенты, но это всего лишь число. Ничто не мешает ошибочно занести в таблицу физ ключ записи клиента, который на самом деле юр.

На составной ключ можно наложить constraint, и тогда SQL сервер просто не примет такую ошибочную транзакцию. Хороший код должен защищать целостность данных.

[Sundersson]

Сообщение от Steelcraft

Когда-то я много работал с реляционными базами данных и часто сталкивался с подобной ситуацией. Использовал нотацию IDEF1X и отношение категоризации. Попробуйте поискать в этом направлении.

Спасибо, очень помогло!

Сообщение от Steelcraft

Целесообразно еще в таблицах юр и физ ввести составной внешний ключ по полям id+type_id таблицы клиентов. Дополнительный контроль целостности (не позволит юрам ссылаться на записи для физов и наоборот).

а можно поподробнее?

[Sundersson]

Сообщение от Valick

1 таблица Клиенты
id - идентификатор строки (идентификатор клиента)
type_id - тип клиента
(далее общие поля для клиентов не зависищие от типа)
...

спасибо за подробный пример таблиц