EF Inheritance Relationship Mapping

Three strategies for inheriting mapping policies

There is following three different approaches to represent a inheritance hierarchy in Code first:

1. Table per Hierarchy (TPH): This approach suggests one table for entire class inheritance hierarchy. Table includes discriminator column which distinguish between inheritance classes. This was a default inheritance mapping strategy in Entity Framework.
2. Table per Type (TPT): This approach suggests seperate table is the domain class.
3. Table per concrete Class (TPC): This approach suggests one table for one concrete class, and not for the abstract class. So if you inherit the abstract class in multiple concrete classes then the properties of the abstract class would be is part O f Each table of concrete class.

Code First has the following three different ways to represent an inheritance hierarchy:

1. One table per hierarchy (TPH): This method indicates that a table inherits a hierarchy for the entire class. The table includes a distinguished inheritance class for the discriminator column (discriminator). This is the default inheritance mapping policy in the Entity Framework.
2. One table per type (TPT): This method displays separate tables for each domain class.
3. One table per specific class (TPC): This method shows a table as a concrete class, not an abstract class. So if you inherit an abstract class in more than one specific class then abstract the properties of the class as part of each table-specific class.

----------------------------------------------------------------------------

---------------------------------------------------

Scenarios for three strategies

I want to emphasize that there are no one single "best strategy fits all scenarios" exists. As you saw, each of the approaches has their own advantages and drawbacks. Here is some rules of thumb to identify the best strategy in a particular scenario:

2. If you don ' t require polymorphic associations or queries, lean toward tpc-in other words, if you never or rarely query for Billingdetails and you had no class that had a association to Billingdetail base class. I recommend TPC (only) for the top level of your class hierarchy, where polymorphism is ' t usually required, and when Modi Fication of the base class in the unlikely.
   
4. If you do require polymorphic associations or queries, and subclasses declare relatively few properties (particularly if t He main difference between subclasses is in their behavior), lean toward TPH. Your goal is to minimize the number of nullable columns and to convince yourself (and Your DBA) that a denormalized schema Won ' t create problems in the long run.
   
6. If you do require polymorphic associations or queries, and subclasses declare many properties (subclasses differ mainly by The data they hold), lean toward TPT. Or, depending on the width and depth of your inheritance hierarchy and the possible cost of joins versus unions, use TPC.
   

By default, choose TPH is simple problems. For more complex cases (or if you ' re overruled by a data modeler insisting on the importance of nullability constraints and normalization), you should consider the TPT strategy. But at this point, ask yourself whether it may is better to remodel inheritance as delegation in the object model (Del Egation is a-making composition as powerful for reuse as inheritance). Complex inheritance is often best avoided for all sorts of reasons unrelated to persistence or ORM. EF acts as a buffer between the domain and relational models, but this doesn ' t mean you can ignore persistence concerns WH En designing your classes.

I want to emphasize that there is no single "best strategy for all scenarios" exists. As you can see, each method has its own pros and cons. Here are some rules of thumb to determine the best strategy in a given situation:

1. If you do not need polymorphic associations or queries, tend to tpc--in other words, if you have never or rarely queried billingdetails and you do not have class associations billingdetail base classes. I recommend TPC (only) the top-level polymorphism of your class hierarchy is not often required and is unlikely to modify the base class in the future.
2. If you need a polymorphic association or query, and the subclass has a relative definition of several properties (especially if the primary difference between subclasses is in their behavior), it tends to TPH. Your goal is to minimize the number of nullable columns and convince yourself (and your DBA) that non-normalized schemas will not cause problems in the long term.
3. If you need to use polymorphic associations or queries, and subclasses (primarily by subclasses whose data they own) define a number of attributes, tend to TPT. Or, if you take into account the width and depth of the inheritance hierarchy and the possible costs of joins and unions, use TPC.

By default, selecting TPH is only a simple issue. For more complex situations (or when you are overturning the importance of nullability constraints and normalization persisted by data modelers), you should consider the TPT strategy. But at this point, ask yourself if it is possible to modify the inheritance in the object model with delegation (the delegation is as powerful a composition as a way of inheriting). Complex inheritance is often best avoided through many reasons unrelated to persistence or ORM. While EF acts as a buffer between domain and relational models, this does not mean that you can ignore content that concerns persistence when designing your class.

Reference

1. Inheritance with EF Code first:table per Hierarchy (TPH)
2. Inheritance with EF Code first:table per Type (TPT)
3. Inheritance with EF Code first:table per concrete class (TPC)

EF Inheritance Relationship Mapping