ДОБРОГО ВРЕМЕНИ СУТОК, может быть кто-то уже сталкивался с такого рода дилеммой - тогда подскажите все + и - в дальнейшей разработке:
1. описание предметной области
есть 6 основных типов сущностей реального мира(физ, юр лицо, ардес, недвижимость, автомобиль, событие).
есть их связи (в итоге их получается более 40, т.к. на 2 одинаковых типа сущностей может быть более одного типа связей) - и это тоже базовые таблицы

Задача - устанавливать ВЗАИМОСВЯЗИ между объектами по их атрибутам, связям, атрибутам связей(реже).

первое напрашивающееся решение - ввести общую таблицу "Objects" всех сущностей, и relationship(foreign key) на нее из 6-и базовых табл.
+ ввести общую таблицу связей (как кросс-таблицу Objects М:М Objects) и relationship(foreign key) на нее из всех 40+ таблиц связей.

тогда мы одним запросом вроде бы получаем SELECT для всех взаимосвязей нашего объекта, несмотря на то - с кем он связан, и каков тип этой связи пока все замечательно,
НО
после нахождения всех взаимосвязанных объектов нам НЕОБХОДИМО ПРИМЕНИТЬ СЕМАНТИКУ ПРЕДМЕТНОЙ ОБЛАСТИ - т.е. отдельно рассматривать найденные связанные объекты из SELECT В_ЗАВИСИМОСТИ от их типа - т.е. приходим к тем же нескольким запросам, от которых мы хотели уйти, но на более позднем этапе.

БОЛЕЕ ТОГО: в этом случае для ускорения работы (а фактически для НЕ ЗАМЕДЛЕНИЯ) необходимо хранить еще и ТИП СВЯЗИ - что является избыточными данными, т.к. он МОЖЕТ БЫТЬ ОПРЕДЕЛЕН из наличия relationship(foreign key) из одной из наследованных таблиц к общей.

ИТОГ: мы создаем надтип, делаем для него запрос, НО потом при работе с этим запросом приходится использовать особенности подтипа. дальше пока не смотрел, т.к. это решение будет краеугольным, если кто сталкивался с подобным - подскажите как по опыту: стоят ли надтипы их применения.

П.С.
(английские понятия применены для объектов базы, русские - объектов предметной области, иначе бы возникла путаница)

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

там где "связь" - это связь реального мира! а для моделирования (базы), я специально во избежание путаницы, применял понятие relftionship (foreign key).

связи - это связь из предметной области (например:
человек(Table) - (1) Работает в орг-ии (table) - Юр лицо (Table)
человек (Table) - (2) учредитиль орг-ии(table) - юр. лицо (table)

и вот таких таблиц связей (1) (2) ..... будет 40+ (в каждой собственный, семантически обособленный, набор атрибутов(полей)).
и одна общая таблица для их унификации, так вот нужна ли она?
если после мы все равно переходим к семантике и рассматпиваем КОНКРЕТНЫЕ таблицы.


Есть еще 1 вариант - но он мне НЕ нравится - создать таблицу Connections (fromConnectedID, toConnectedID, ConnectionType), и к ней по внешним ключам присоединять таблицы для ВСЕХ ВОЗМОЖНЫХ СВОЙСТВ КАЖДОГО ИЗ ПОДТИПОВ, и на уровне логики приложения выбирать - какие свойства нужны для конкретного запроса поиска.
НО это будет вообще лишенная "смысла", невыразительная база.

(туда же)
т.е. на уровне базы КАЖДЫЙ объект потенциально обладает ВСЕМ ВОЗМОЖНЫМ НАБОРОМ СВОЙСТВ.
и на уровне базы не отражено: допустимо ли данное свойство для объекта - а лишь на уровне приложения.

_мод _Kostyan_связи - это связь из предметной области (например:
человек(Table) - (1) Работает в орг-ии (table) - Юр лицо (Table)
человек (Table) - (2) учредитиль орг-ии(table) - юр. лицо (table)

Это не связи - это свойства объекта человек. Их тип- ссылка на объект(ы) типа Юр лицо.

уже понял, что топик получился непонятным с 1-го раза.
связи (пр. области) = кросс. таблица свойств (БД)..... (и еще много непонятного).

думаю, что этой непонятностью тема загублена, а править тут сообщения нельзя.

НАВЕРНОЕ ЗАКРЫТО.

Чендлер2_Kostyan_
ты в СБ работаешь?
программист .

mcureenabС другой стороны, связи "Работает в, "Учредитель", и т.п. вообще говоря достойны того, чтобы завести для них нормальные таблицы, типа "Трудовая книжка", "Трудовой контракт", не знаю точно... "Устав фирмы", и т.п. Кроме того, бывают многосторонние связи объектов.

1. отдельные таблицы заведены - но это "за пределами ядра" базы, т.е. эти связи НЕ ПОВЛИЯЮТ НА ОРГАНИЗАЦИЮ КРОСС-СВЯЗЕЙ, поэтому я их не стал упоминать (там 2-ые и 3-ые словати есть на самом деле)

2. многосторонние связи уже учтены, но если говорить о них - вообще непонятно ничего будет. (вернее понятно после прочтения 2-х стр. текста.

вообще все НАГЛЯДНО в другой теме.

Чендлер _Kostyan_ Чендлер2_Kostyan_
ты в СБ работаешь?
программист .
в аську заглини

ага, только вечером :(
(бтв. ты как "гость" вошел)