Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Entity Framework 4 Tabela por hierarquia - Como definir propriedades de navegação em filhos?


Então eu resolvi alguns dos meus problemas, mas eu bati em uma parede de tijolos.

Em primeiro lugar, quando você cria FKs auto-referenciados no lado do banco de dados, quando você tenta "Atualizar o modelo do banco de dados", o Entity Framework adicionará essas propriedades de navegação ao tipo base principal, pois não tem um sentido explícito de TPH - você precisa fazer isso no lado do modelo.

MAS, você pode adicionar manualmente as propriedades de navegação aos tipos filho.

WRT este erro:

Isso porque eu tinha um FK chamado "Location_State" que eu estava tentando usar para o relacionamento "ZipCode_State" E o relacionamento "City_State" - que não funciona (ainda não faço ideia do porquê).

Então, para resolver isso, eu tive que adicionar colunas extras e FKs extras - um chamado "ZipCode_State" e outro chamado "City_State" - obviamente, tem que ser um 1-1 entre navs e FKs físicos.

Esse é o meu campo discriminador. No lado do banco de dados, é não anulável .

Eu li tópicos sobre esse problema e eles disseram que você precisa alterar os relacionamentos de 0..* para 1..* - mas meus relacionamentos já eram 1..*.

Se você olhar para a minha tabela de banco de dados real "Locations" acima, todos os FKs são anuláveis ​​(eles precisam ser). Por isso comecei a me perguntar se meus relacionamentos deveriam ser 0..*.

Mas eles são anuláveis ​​por causa do TPH - nem todos os "Locations" terão um "State". Mas se esse Local for uma "Cidade", então TEM que ter um "Estado".

Meus sentimentos foram ainda mais confortados por esta pergunta SO:ADO EF - Erros de mapeamento de associações entre tipos derivados em TPH

Na verdade, eu estava tentando essa solução alternativa (antes mesmo de encontrá-la) e a solução alternativa não funciona para mim. Eu até tentei mudar todas as relações de 1..* para 0..*, e ainda sem sorte.

Perdendo muito tempo aqui, voltei ao TPT.

No final das contas, com o TPH eu teria uma tabela ridiculamente grande, com muitas e muitas colunas redundantes e anuláveis. JOIN-wise, é mais eficiente. Mas pelo menos com o TPT eu não sou obrigado a ter FKs anuláveis ​​e auto-referenciados.

Se alguém tiver uma solução para este problema, me avise. Mas até lá, estou aderindo ao TPT.