У меня есть устаревшая база данных, которая имеет несколько таблиц, которые были разработаны с использованиемПолиморфные Ассоциации, Под полиморфными ассоциациями я подразумеваю, что эти таблицы могут быть дочерними по отношению к различным таблицам согласно столбцу.ObjectType.

Пример:

Documents стол имеетDocumentID (первичный ключ идентификации), некоторые другие столбцы и 2 специальных столбца, называемыхObjectType а такжеObjectID.ЕслиObjectType='STUDENT', ObjectID указывает наStudents Таблица.ЕслиObjectType='TEACHER', ObjectID указывает наTeachers стол и т. д.

Это похоже наэтот дизайн (как описано в «подходе без внешнего ключа») илиэтот (описывается как анти-шаблон). И, очевидно, естьнет ограничений по внешнему ключу на этих столбцах(AFAIK никакая база данных не позволила бы такие отношения).

Я пишу новый уровень доступа к данным, используя Entity Framework 6 (сначала код с Fluent API), который должен работать бок о бок с существующим кодом. Так как эта структура базы данных была развернута для сотен разных клиентов (у каждого из которых была своя кодовая база и разные настройки базы данных), изменение структуры существующих таблиц не вариант.

Мой вопрос: как мне отобразить эти полиморфные ассоциации в мою модель кода EF?

РЕДАКТИРОВАТЬКажется, я пытался спроектировать иерархию классов на неправильных объектах. Насколько я понимаю, у меня было много «GenericChildTables» (таких как Documents), которые должны указывать на (несуществующий) объект, который имел бы составной ключ ObjectType + ObjectID. А затем я пытался создать эту новую сущность (назовем ее «BusinessObject») и отобразить мои основные сущности (учащиеся, учителя и т. Д.) Как подтипы этого BusinessObject.

ЭТО дизайн, вероятно, был просто неправильным и, возможно, совершенно невозможным, потому что создаваемая мной новая таблица (BusinessObject) зависела от StudentID / TeacherID и т. Д., Поэтому она не могла быть родительской для этих таблиц. Используя некоторые уродливые обходные пути, я мог создать этот BusinessObject как отдельный дочерний элемент для каждой основной сущности и сопоставить эти BusinessObjects с полиморфными таблицами, и он действительно работал, но в совершенно неправильном дизайне.

затем Я виделВопрос Герта Ардольда и понял, что то, что должно быть спроектировано как иерархия классов, это НЕ Студенты / Учителя / и т. д. (сгруппированные в общую сущность), а каждый из этих ChildTables, которые содержали различные подтипы в соответствии сObjectType дискриминатор - это те типы, которые следует разбить на подтипы.Смотрите мое решение на мой собственный ответ ниже.