Takže jsem vyřešil několik svých problémů, ale narazil jsem na cihlovou zeď.
Za prvé, když vytvoříte samoodkazující FK na straně databáze, když se pokusíte "Aktualizovat model z databáze", Entity Framework přidá tyto navigační vlastnosti do hlavního základního typu, protože nemá žádný explicitní význam TPH - vy musíte to udělat na straně modelu.
K podřízeným typům ALE můžete ručně přidat navigační vlastnosti.
WRT tuto chybu:
Bylo to proto, že jsem měl FK s názvem "Location_State", který jsem se pokoušel použít pro vztah "ZipCode_State" A vztah "City_State" - což nefunguje (stále nevím proč).
Abych to vyřešil, musel jsem přidat další sloupce a další FK - jeden s názvem "ZipCode_State" a druhý s názvem "City_State" - samozřejmě to musí být 1-1 mezi navigačními a fyzickými FK.
To je moje diskriminační pole. Na straně databáze není možné nulovat .
Četl jsem vlákna o tomto problému a řekli, že musíte změnit vztahy z 0..* na 1..* - ale moje vztahy už byly 1..*.
Pokud se podíváte na moji skutečnou databázovou tabulku "Umístění" výše, všechny FK jsou nulovatelné (musí být). Proto jsem začal přemýšlet, jestli by moje vztahy měly být 0..*.
Ale mohou být zrušeny kvůli TPH - ne všechny "Místa" budou mít "Stát". Ale pokud je toto místo "Město", pak MUSÍ mít "Stát".
Mé pocity dále uklidnila tato otázka:ADO EF – Mapování chyb přidružení mezi odvozenými typy v TPH
Ve skutečnosti jsem to řešení zkoušel (než jsem na něj narazil) a toto řešení pro mě nefunguje. Dokonce jsem zkoušel změnit všechny vztahy z 1..* na 0..* a stále bez úspěchu.
Ztrácel jsem zde příliš mnoho času a vrátil jsem se k TPT.
Na konci dne bych s TPH měl směšně velkou tabulku se spoustou a spoustou nadbytečných sloupců s možností null. Z hlediska JOIN je to efektivnější. Ale alespoň s TPT nemusím mít FK s možností nulování a odkazující na sebe.
Pokud má někdo řešení tohoto problému, dejte mi vědět. Ale do té doby zůstanu u TPT.