Ich habe eine alte Datenbank mit einigen Tabellen, die mit @ erstellt wurdeolymorphe Assoziation. Mit polymorphen Assoziationen meine ich, dass diese Tabellen gemäß einer Spalte @ untergeordnete Elemente verschiedener Tabellen sein könneObjectType.

Beispiel

Documents table hasDocumentID (Identitätsprimärschlüssel), einige andere Spalten und 2 spezielle Spalten mit dem NamenObjectType undObjectID.WennObjectType='STUDENT', ObjectID verweist aufStudents TabelleWennObjectType='TEACHER', ObjectID verweist aufTeachers table, etc.

Dies ist ähnlich wiedieses Design (wie im "no foreign key approach" beschrieben) oderdiese (als Anti-Pattern bezeichnet). Und natürlich gibt eskeine Fremdschlüsseleinschränkungen auf diesen Spalten (AFAIK keine Datenbank würde diese Art von Beziehung zulassen).

Ich schreibe eine neue Datenzugriffsschicht mit Entity Framework 6 (Code-first mit Fluent API), die neben dem vorhandenen Code funktionieren soll. Da diese Datenbankstruktur für Hunderte verschiedener Kunden bereitgestellt wurde (jeder mit einer anderen Codebasis und unterschiedlichen Datenbankanpassungen), kann die Struktur vorhandener Tabellen nicht geändert werden.

Meine Frage lautet: Wie ordne ich diese polymorphen Assoziationen meinem EF-Code-First-Modell zu?

BEARBEITE: Es scheint, dass ich versucht habe, die Klassenhierarchie für die falschen Entitäten zu entwerfen. Mein Verständnis war, dass ich viele "GenericChildTables" (wie Dokumente) hatte, die auf eine (nicht vorhandene) Entität verweisen sollten, die einen zusammengesetzten Schlüssel ObjectType + ObjectID haben würde. Und dann habe ich versucht, diese neue Entität zu erstellen (nennen wir sie "BusinessObject") und meine Kernentitäten (Schüler, Lehrer usw.) als Untertypen dieses BusinessObjects zuzuordnen.

THAT Design war wahrscheinlich einfach falsch und möglicherweise völlig unmöglich, da diese neue Tabelle, die ich erstellte (BusinessObject), von StudentID / TeacherID usw. abhing, sodass sie kein übergeordnetes Element dieser Tabellen sein konnte. Unter Verwendung einiger hässlicher Problemumgehungen konnte ich dieses BusinessObject als einzelnes untergeordnetes Objekt für jede Kernentität erstellen und diese BusinessObjects den polymorphen Tabellen zuordnen, und es funktionierte tatsächlich, jedoch in einem völlig falschen Design.

Dan Ich sahGert Ardolds Frage und erkannte, dass das, was als Klassenhierarchie entworfen werden sollte, NICHT Schüler / Lehrer / etc (zusammengefasst in eine generische Entität) war, sondern jede dieser ChildTables, die unterschiedliche Subtypen entsprechend dem @ enthielteObjectType discriminator - das waren die Typen, die in Untertypen aufgeteilt werden sollten.Siehe meine Lösung in meiner eigenen Antwort unten.