Więc rozwiązałem kilka moich problemów, ale trafiłem na ceglaną ścianę.
Przede wszystkim, gdy tworzysz FK odwołujące się do siebie po stronie bazy danych, gdy próbujesz "Aktualizuj model z bazy danych", Entity Framework doda te właściwości nawigacyjne do głównego typu bazowego, ponieważ nie ma wyraźnego sensu TPH - ty trzeba to zrobić po stronie modelu.
ALE możesz ręcznie dodać właściwości nawigacyjne do typów podrzędnych.
WRT ten błąd:
To dlatego, że miałem FK o nazwie „Location_State”, którego próbowałem użyć do relacji „ZipCode_State” ORAZ relacji „City_State” – która nie działa (nadal nie mam pojęcia dlaczego).
Aby rozwiązać ten problem, musiałem dodać dodatkowe kolumny i dodatkowe FK – jedną o nazwie „ZipCode_State”, a drugą o nazwie „City_State” – oczywiście musi to być 1-1 między nawigacją a fizycznymi FK.
To jest moje pole dyskryminacyjne. Po stronie bazy danych nie można zerować .
Czytałem wątki na ten temat i powiedzieli, że musisz zmienić relacje z 0..* na 1..* - ale moje relacje były już 1..*.
Jeśli spojrzysz na moją tabelę rzeczywistej bazy danych "Lokalizacje" powyżej, wszystkie FK są nullable (muszą być). Dlatego zacząłem się zastanawiać, czy moje relacje powinny wynosić 0..*.
Ale są nieważne ze względu na TPH - nie wszystkie "Lokalizacje" będą miały "Stan". Ale jeśli ta lokalizacja to „Miasto”, MUSI mieć „Stan”.
Moje uczucia dodatkowo pocieszyło to pytanie SO:ADO EF — Błędy mapowania powiązań między typami wyprowadzonymi w TPH
Właściwie próbowałem tego obejścia (zanim nawet się z nim natknąłem), a obejście nie działa dla mnie. Próbowałem nawet zmienić wszystkie relacje z 1..* na 0..* i nadal nie miałem szczęścia.
Tracę tu zbyt dużo czasu, wróciłem do TPT.
Pod koniec dnia, z TPH, miałbym absurdalnie duży stół, z mnóstwem zbędnych, zerowych kolumn. JOIN jest bardziej wydajny. Ale przynajmniej w przypadku TPT nie muszę mieć wartości null i samoodnoszących się FK.
Jeśli ktoś ma rozwiązanie tego problemu to dajcie znać. Ale do tego czasu trzymam się TPT.
