sql >> Base de Datos >  >> RDS >> Sqlserver

Entity Framework 4 Tabla por jerarquía:¿cómo definir las propiedades de navegación en los niños?

Así que resolví algunos de mis problemas, pero me topé con una pared de ladrillos.

En primer lugar, cuando crea FK autorreferenciales en el lado de la base de datos, cuando intenta "Actualizar el modelo desde la base de datos", Entity Framework agregará estas propiedades de navegación al tipo base principal, ya que no tiene un sentido explícito de TPH:usted necesita hacer esto en el lado del modelo.

PERO, puede agregar manualmente las propiedades de navegación a los tipos secundarios.

WRT este error:

Eso fue porque tenía un FK llamado "Location_State" que intentaba usar para la relación "ZipCode_State" Y la relación "City_State", que no funciona (todavía no tengo idea de por qué).

Entonces, para resolver eso, tuve que agregar columnas adicionales y FK adicionales, una llamada "ZipCode_State" y otra llamada "City_State". Obviamente, tiene que ser un 1-1 entre navs y FK físicos.

Ese es mi campo discriminador. En el lado de la base de datos, es no anulable .

Leí hilos sobre este problema y dijeron que necesita cambiar las relaciones de 0..* a 1..* - pero mis relaciones ya eran 1..*.

Si observa la tabla de base de datos real de "Ubicaciones" anterior, todos los FK son anulables (tienen que serlo). Por lo tanto, comencé a preguntarme si mis relaciones deberían ser 0..*.

Pero son anulables debido al TPH:no todas las "Ubicaciones" tendrán un "Estado". Pero si esa Ubicación es una "Ciudad", entonces TIENE que tener un "Estado".

Mis sentimientos se consolaron aún más con esta pregunta SO:ADO EF - Asociaciones de mapeo de errores entre tipos derivados en TPH

De hecho, estaba intentando esa solución alternativa (antes incluso de encontrarla), y la solución alternativa no funciona para mí. Incluso intenté cambiar todas las relaciones de 1..* a 0..*, y aún no tuve suerte.

Perdiendo demasiado tiempo aquí, he vuelto a TPT.

Al final del día, con TPH habría tenido una tabla ridículamente grande, con montones y montones de columnas anulables y redundantes. JOIN-sabio, es más eficiente. Pero al menos con TPT no estoy obligado a tener FK anulables y autorreferenciales.

Si alguien tiene una solución a este problema, hágamelo saber. Pero hasta entonces, me quedo con TPT.