Héritage Entity Framework: TPT, TPH ou aucun?

entity-framework inheritance

Question

Je suis en train de lire sur la possibilité d'utiliser l'héritage avec Entity Framework. Parfois, j'utilise une méthode pour taper des enregistrements de données et je ne suis pas sûr d'utiliser TPT, TPH ou aucun.

Par exemple ... J'ai un magasin en ligne qui ajoute l'adresse de livraison, de facturation et de livraison

J'ai une table d'adresses:

RecordID
AddressTypeID
Street
ZipCode
City
Country

et une table AddressType

RecordID
AddressTypeDescription

La conception de la table diffère de la conception générale lorsque les gens montrent du TPT ou de la TPH ... Cela a-t-il un sens de penser à l'héritage et d'avoir une telle approche ..

J'espère que ça a du sens...

Merci pour toute aide...

Réponse acceptée

Vous devriez consulter ma série de conseils EF .

Celui intitulé Comment choisir une stratégie d'héritage devrait vous donner plus de perspicacité

J'espère que cela t'aides

Alex


Réponse populaire

Lorsque vous envisagez de représenter l'héritage dans la base de données, vous devez prendre en compte quelques éléments.

Si vous avez plusieurs sous-classes différentes, vous pouvez avoir beaucoup de jointures supplémentaires dans les requêtes impliquant des types plus complexes qui peuvent nuire aux performances. L'un des grands avantages de TPH est que vous interrogez une table pour tous les types de la hiérarchie, ce qui est un avantage en termes de performances, en particulier pour les hiérarchies plus grandes. Pour cette raison, j'ai tendance à privilégier cette approche dans la plupart des scénarios.

Cependant, TPH signifie que vous ne pouvez plus avoir de champs NOT NULL pour les sous-types car tous les champs de tous les types sont dans une seule table, ce qui pousse la responsabilité de l'intégrité des données vers votre application. Bien que cela puisse paraître horrible en pratique, je n’ai pas trouvé cette restriction trop lourde.

Cependant, j'aurais tendance à utiliser TPT s'il y avait beaucoup de champs pour chaque type et que le nombre de types dans la hiérarchie était probablement petit, ce qui signifie que les performances n'étaient pas vraiment un problème avec les jointures et que vous obteniez de meilleurs résultats. intégrité des données.

Notez que l'un des avantages de EF et des autres ORM est que vous pouvez changer d'idée sur la piste sans impacter votre candidature, de sorte que la décision n'a pas besoin d'être complètement gravée dans le marbre.

Dans votre exemple, il ne semble pas y avoir de relation d'héritage, cela ressemble à un un à plusieurs, du type d'adresse aux adresses.

Ce serait représenté entre vos classes quelque chose comme ce qui suit:

Address.AddressType
AddressType.Addresses


Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow