Three inheritance policies supported by nhib.pdf [Abstract]

The following describes the advantages and disadvantages of these three ing policies one by one:

1. Table per concrete class

In this way, we need to map every subclass to a table and all attributes of this subclass (including all attributes of the parent class) to a table.

The biggest problem with this method is the lack of good support for polymorphism. Associations in databases are generally reflected by foreign keys. If all the child classes are mapped to different tables separately, the sub-classes cannot perform multi-state relations on the parent class through a simple foreign key. This will cause problems in our domain model. Billdetails will certainly be associated with other classes, such as the user class, so both tables must be referenced by a foreign key to the user table.

Multi-state query (query and return all the interface classes that match the Query Class) also produces problems. For the query of the parent class, you need to execute multiple select statements, one for each subclass. Will seriously affect the performance.

Another serious problem is that if the parent class is modified, it will cause modifications to all subclass-related columns and ing files.

This ing policy does not have a special label in nhib.pdf. You only need to create a new <class> Declaration for each specific class and specify a table attribute. This ing policy can be used only when the benefits of inheritance can be abandoned. Otherwise, it is absolutely not recommended.

2. Table per class hierarchy

This ing policy requires that the entire inheritance system be fully mapped to a table. All attributes of all classes in the entire inheritance system are mapped to each column of the table. Each subclass represents a row identified by the discriminator column in the table.

This ing policy is the simplest and best performing among the three policies. However, this method also has a major problem. attributes defined by sub-classes must be defined as null for columns in the database. This will lose the constraints of the database on not null. From the perspective of data integrity, the problem is very serious :)

In Nhibernate, we use the <subclass> element to define the table-per-class hierarchy ing. The ing file is as follows:

<Hibernate-mapping>
<Class table = "billing_details" discriminator-value = "BD">
<ID column = "billing_details_id" type = "long">
<Generator/>
</ID>
<Discriminator column = "billing_details_type" type = "string"/>
<Property column = "owner" type = "string"/>
...
<Subclass discriminator-value = "cc">
<Property column = "credit_card_type"/>
...
</Subclass>
...
</Class>
</Hibernate-mapping>

Discriminator is not a persistent class attribute. It is only used to distinguish each persistent class in the inheritance system. It is only used within the Nhibernate. The name of this column is billing_details_type. In this example, the value of this column is set to CC and BD, and Nhibernate automatically obtains or sets the value of this column. That is to say, each row in the table represents a class in the inheritance system, which is distinguished by the different values of billing_details_type. CC indicates that this row corresponds to the creditcard class. Each subclass has its own subclass element. The attributes of the subclass are mapped to the columns in the billing_details table. It is worth noting that the not-null attribute must be set to true for the attributes of each subclass, because the creditcard subclass instance cannot all have attributes of other subclass instances. <Subclass> Other <subclass> can be nested until the entire inheritance system is mapped to the table.

3. Table per subclass

The third type is to use a foreign key relationship to represent the inheritance relationship. In this policy, each subclass and parent class are mapped to a table separately. Different from the first policy, the table of this policy only contains the attributes defined by the class (excluding inherited attributes ).

If the instance of the creditcard subclass is persistent, the attributes defined in the billingdetails parent class will also be persistent to the new row in the billing_details table, the attributes defined by the creditcard subclass (excluding inherited attributes) will be persisted to the new row in the credit_card table. The two new rows are associated by the Shared primary key. When the sub-class instances are removed from the database, the join sub-classes and parent classes need to correspond to those tables respectively.

The biggest benefit of this strategy is that the relational model is completely standardized, and the relational model is exactly the same as the domain model. In Nhibernate, <joined-subclass> is used to represent this policy. The ing file is as follows:

<Hibernate-mapping>
<Class table = "billing_details">
<ID column = "billing_details_id" type = "long">
<Generator/>
</ID>
<Property column = "owner" type = "string"/>
...
<Joined-subclass table = "credit_card">
<Key column = "credit_card_id"/>
<Property column = "type"/>
...
</Joined-subclass>
...
</Class>
</Hibernate-mapping>

In this policy, discriminator is not required. The <joined-subclass> element is used to map child classes. In the credit_card table, the primary key is required. It must be associated with the primary key of the billing_details table. <Joined-subclass> can also be nested with other <joined-subclass> elements, but cannot contain <subclass> elements.

This strategy is obviously more complex than other strategies, and the performance is much lower, because a large number of join statements are required. Especially when the inheritance relationship is complex, the problem becomes more serious.