Как сделать(обойти) foreign key на разные таблицы?
Итак имею ООПшную структуру с абстрактным объектом и его наследниками. В другом объекте есть ссылка на родительский класс (куда может записан один из наследников), но при попытке это дело перенести в БД вошел в ступор, т.к. получается FK толи на одну толи на другую таблицу. Как это решается?
Т.е. вопрос именно по структуре таблицы БД.
P.S. Слышал про полиморфные связи и что они зло. Но проблема явно не первый год существует. Как то же ее решают?
Но проблема явно не первый год существует. Как то же ее решают?
Решают её, как Вы уже сами озвучили, либо с помощью полиморфных связей, которые есмь зло, либо с помощью нормализации данных. Без какого-то реального примера, все возможные советы в вашем конкретном случае будут из области "пальце в... небо!".
ОК. Пример:
Есть некая заявка(жирный объект), где есть данные по Клиенту. Клиент - абстрактный класс. У класса Клиент есть два наследника физ. лицо и юр. лицо. Вы не знаете в заявке кто будет клиентом (но точно или один или другой).
Alexander, этот случай гораздо проще -)
Клиент, даже в более развитом варианте - это собственно нечто с заполненными либо данными характерными для юрика, либо физика, либо ИП
То бишь например ИНН - он для всех, а вот ОГРН - скорее для юрика (у физика - null)
То бишь в абстрактном классе существуют общие для любых типов поля, в наследниках трех типов - дополнительные поля, характерные для физика, юрика и ип, а в базе - все поля, включая указание типа.
В итоге - при чтении из базы тип однозначно идентифицирует что за наследник должен быть создан. И обратно - в зависимости от объекта - в базу пишутся нужные поля.
При желании можно допустить и "без типа" и писать самый минимум (некоторые CRM системы подобное реализуют в виде самого верхнего уровня воронки - только имя, которое потом может превратится в контрагента, который физлицо, но является представителем контрагента-юрлица).
Можно убрать констрэйн, но это чревато нарушением консистентности.
Можно в проекциях объектов (таблицах) делать условно избыточность в виде нескольких полей-ссылок и поле типа.
Естественно и то и то не идеал. Но так или иначе приходится искать компромисс между многомерностью (ООП) и ее проекциями (реляционные БД). Отсюда и различные вариант нереляционных БД
Простой
