sql >> Database >  >> RDS >> Sqlserver

Entity Framework 4 Tabel per hiërarchie - Hoe navigatie-eigenschappen voor kinderen definiëren?

Dus ik heb een paar van mijn problemen opgelost, maar ik liep tegen een muur aan.

Allereerst, wanneer u naar zichzelf verwijzende FK's aan de databasezijde maakt, wanneer u probeert en "Model bijwerken vanuit database", zal Entity Framework deze navigatie-eigenschappen toevoegen aan het hoofdbasistype, omdat het geen expliciete betekenis van TPH heeft - u moet dit aan de modelzijde doen.

MAAR, u kunt de navigatie-eigenschappen handmatig toevoegen aan de onderliggende typen.

WRT deze fout:

Dat was omdat ik een FK had met de naam "Location_State" die ik probeerde te gebruiken voor de "ZipCode_State"-relatie, EN de "City_State"-relatie - die niet werkt (nog steeds geen idee waarom).

Dus om dat op te lossen, moest ik extra kolommen en extra FK's toevoegen - een genaamd "ZipCode_State" en een andere genaamd "City_State" - uiteraard moet het een 1-1 zijn tussen navigatiesystemen en fysieke FK's.

Dat is mijn discriminatorveld. Aan de databasekant is het niet nullable .

Ik las discussies over dit probleem en ze zeiden dat je de relaties van 0..* naar 1..* moet veranderen - maar mijn relaties waren al 1..*.

Als je naar mijn "Locaties" werkelijke databasetabel hierboven kijkt, zijn alle FK's nullable (ze moeten dat zijn). Daarom begon ik me af te vragen of mijn relaties 0..* zouden moeten zijn.

Maar ze zijn nullable vanwege de TPH - niet alle "Locaties" hebben een "State". Maar als die Locatie een "Stad" is, dan MOET het een "Staat" hebben.

Mijn gevoelens werden verder getroost door deze SO-vraag:ADO EF - Fouten bij het in kaart brengen van associaties tussen afgeleide typen in TPH

Ik was eigenlijk die tijdelijke oplossing aan het proberen (voordat ik hem zelfs maar tegenkwam), en de oplossing werkt niet voor mij. Ik heb zelfs geprobeerd alle relaties van 1..* naar 0..* te veranderen, maar nog steeds geen geluk.

Omdat ik hier te veel tijd verspil, ben ik teruggegaan naar TPT.

Aan het eind van de dag zou ik met TPH een belachelijk grote tafel hebben gehad, met heel veel overbodige, nullable kolommen. JOIN-wijs is het efficiënter. Maar bij TPT hoef ik tenminste geen nullable en zelfverwijzende FK's te hebben.

Als iemand een oplossing heeft voor dit probleem, laat het me weten. Maar tot die tijd blijf ik bij TPT.




  1. Waarom converteert MySQL tekenreeksen automatisch naar getallen?

  2. MySQL - Waarde aftrekken van de vorige rij, groeperen op

  3. Een database dupliceren met phpMyAdmin

  4. Mysql-toegang geweigerd wegens gebruikersfout?