Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Entity Framework 4 Tabelle pro Hierarchie - Wie werden Navigationseigenschaften für untergeordnete Elemente definiert?

Also habe ich ein paar meiner Probleme gelöst, bin aber auf eine Mauer gestoßen.

Wenn Sie auf der Datenbankseite auf sich selbst verweisende FKs erstellen und versuchen, „Modell aus der Datenbank zu aktualisieren“, fügt Entity Framework diese Navigationseigenschaften dem Hauptbasistyp hinzu, da es keinen expliziten Sinn für TPH – Sie – hat müssen dies auf der Modellseite tun.

ABER Sie können die Navigationseigenschaften manuell zu den untergeordneten Typen hinzufügen.

WRT diesen Fehler:

Das lag daran, dass ich einen FK namens "Location_State" hatte, den ich für die Beziehung "ZipCode_State" UND die Beziehung "City_State" verwenden wollte - was nicht funktioniert (immer noch keine Ahnung warum).

Um das zu lösen, musste ich zusätzliche Spalten und zusätzliche FKs hinzufügen - eine namens "ZipCode_State" und eine andere namens "City_State" - offensichtlich muss es ein 1-1 zwischen Navs und physischen FKs sein.

Das ist mein Unterscheidungsfeld. Auf der Datenbankseite ist es nicht nullable .

Ich habe Threads zu diesem Problem gelesen, und sie sagten, Sie müssten die Beziehungen von 0..* auf 1..* ändern - aber meine Beziehungen waren bereits 1..*.

Wenn Sie sich meine tatsächliche Datenbanktabelle "Standorte" oben ansehen, sind alle FKs nullable (sie müssen es sein). Daher fing ich an mich zu fragen, ob meine Beziehungen 0..* sein sollten.

Aber sie sind wegen des TPH nullable - nicht alle "Locations" haben einen "State". Aber wenn dieser Ort eine "Stadt" ist, dann MUSS er einen "Staat" haben.

Meine Gefühle wurden durch diese SO-Frage weiter getröstet:ADO EF – Fehler bei der Zuordnung von Zuordnungen zwischen abgeleiteten Typen in TPH

Ich habe diese Problemumgehung tatsächlich versucht (bevor ich überhaupt darauf gestoßen bin), und die Problemumgehung funktioniert bei mir nicht. Ich habe sogar versucht, alle Beziehungen von 1..* auf 0..* zu ändern, aber immer noch kein Glück.

Da ich hier zu viel Zeit verschwende, bin ich zu TPT zurückgekehrt.

Am Ende des Tages hätte ich mit TPH eine lächerlich große Tabelle mit vielen, vielen redundanten, nullbaren Spalten gehabt. JOIN-weise ist es effizienter. Aber zumindest mit TPT muss ich keine nullfähigen und selbstreferenzierenden FKs haben.

Wenn jemand eine Lösung für dieses Problem hat, lass es mich wissen. Aber bis dahin bleibe ich bei TPT.