Как сделать(обойти) foreign key на разные таблицы?

Question

[Alexander]

Итак имею ООПшную структуру с абстрактным объектом и его наследниками. В другом объекте есть ссылка на родительский класс (куда может записан один из наследников), но при попытке это дело перенести в БД вошел в ступор, т.к. получается FK толи на одну толи на другую таблицу. Как это решается?
Т.е. вопрос именно по структуре таблицы БД.

P.S. Слышал про полиморфные связи и что они зло. Но проблема явно не первый год существует. Как то же ее решают?

Comments

[Евгений Вольф]

Но проблема явно не первый год существует. Как то же ее решают?

Решают её, как Вы уже сами озвучили, либо с помощью полиморфных связей, которые есмь зло, либо с помощью нормализации данных. Без какого-то реального примера, все возможные советы в вашем конкретном случае будут из области "пальце в... небо!".

[Alexander]

ОК. Пример:
Есть некая заявка(жирный объект), где есть данные по Клиенту. Клиент - абстрактный класс. У класса Клиент есть два наследника физ. лицо и юр. лицо. Вы не знаете в заявке кто будет клиентом (но точно или один или другой).

[d-stream]

Alexander, этот случай гораздо проще -)
Клиент, даже в более развитом варианте - это собственно нечто с заполненными либо данными характерными для юрика, либо физика, либо ИП
То бишь например ИНН - он для всех, а вот ОГРН - скорее для юрика (у физика - null)

То бишь в абстрактном классе существуют общие для любых типов поля, в наследниках трех типов - дополнительные поля, характерные для физика, юрика и ип, а в базе - все поля, включая указание типа.
В итоге - при чтении из базы тип однозначно идентифицирует что за наследник должен быть создан. И обратно - в зависимости от объекта - в базу пишутся нужные поля.

При желании можно допустить и "без типа" и писать самый минимум (некоторые CRM системы подобное реализуют в виде самого верхнего уровня воронки - только имя, которое потом может превратится в контрагента, который физлицо, но является представителем контрагента-юрлица).

Answer 1

[d-stream]

Можно убрать констрэйн, но это чревато нарушением консистентности.
Можно в проекциях объектов (таблицах) делать условно избыточность в виде нескольких полей-ссылок и поле типа.
Естественно и то и то не идеал. Но так или иначе приходится искать компромисс между многомерностью (ООП) и ее проекциями (реляционные БД). Отсюда и различные вариант нереляционных БД