explaspно ведь и при такой реализации (которую я и использовал, но не до конца) просле того как приложение запущено уже неважно что там больше joinov
Лишие join'ы сильно влияют на производительность системы. Но выбор реализации конструкции наследования типов выходит за рамки данного форума. Нужно смотреть на конкретную СУБД и другие технические показатели, как то объём данных, методы доступа к таблицам, требования к производительности и д.р..
Ведь можно забить на ссылочную целостность и сделать так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
table Физ_Лица (
<атрибуты типа Лицо>,
<атрибуты типа Физ_Лицо>,
ID
);
table ЮР_Лица (
<атрибуты типа Лицо>,
<атрибуты типа ЮР_Лицо>,
ID
);
table Договор (
<прочие атрибуты>
заказчик, -- тут был references Лица, пока мы не удалили таблицу Лица
исполнитель, -- тут был references Лица, пока мы не удалили таблицу Лица
представитель_заказчика, -- тут был references Лица, пока мы не удалили таблицу Лица
);
где ID заполнять из общего счётчика. И т.д. и т.п. На самом деле ссылка из Договора на Лицо не есть лучшее решение. По сути, эта ссылка вычисляемая, если непосредственно в Договоре указаны реквизиты сторон. Если ограничиться только ссылками, такое вычисление должен будет выполнять оператор, который заводит договор. Если в договор включить реквизиты сторон, то такое вычисление может сделать машина и сохранить результат для дальнейшего использования. При изменении даных Лица, машина сможет проконтролировать и пересчитать ссылки, сообщить о том, что в договор нужно внести изменения.
А вот эта идея мне кажется стоящей для рассмотрения, на первый взгляд она может решить все проблемы, но необходимо посмотреть внимательней
