This article is about hibernate inheritance. Here we will be disussing about the different inheritance strategy supported by hibernate such as Single Table Strategy, Table per class strategy and Joined strategy along with their advantages and disadvantages. We will be creating code samples for each strategy and discuss about their behaviour in a great detail.
As we know Java is an object oriented language and hence it supports inheritance. In java inheritance, there can be IS-A or HAS-A relationship. But when we come to any relational model, it supports only HAS-A relationship. To overcome this mimmatch hibernate provides different inheritance strategy. There are basically 3 types of hibernate strategy as follows.
1. Single Table Strategy
2. Table Per Class Strategy
3. Joined Table Strategy
Now let us discuss about these 3 strategies one by one. In the examples below, we have 3 different entities. The parent entity
Employee.java is being extended by 2 other entities
In case of single table strategy, there is a single table created per inheritance hierachy. For example, we have Employee class being extended by 2 others classes but when it comes to single table strategy a single table will be created representing all the classes per inheritance hieracy and this table will contain all the data related to either Employee or ContractEmployee or PermanentEmployee.
So, the question arises as if all the entries are made in a single table then how can we identify those rows from object perspective. For this, hbernate provides a Discriminator Type(DType) column which helps to differentiate between these records. This configuration is completely annotation based. So let us define our entities and implement hibernate inheritance with Single Table Strategy.
@Inheritance - It is used to define the type of inheritance used in hibernate and it is defined in the parent class. If the Inheritance annotation is not specified or if no inheritance type is specified for an entity class hierarchy, the SINGLE_TABLE mapping strategy is used.
@DiscriminatorValue - This annotation is used to specify the DType column name. Here we have defined it as
PERMANENT_EMP in case of
CONTRACT_EMPLOYEE in case of
ContractEmployee.java. The DiscriminatorValue annotation can only be specified on a concrete entity class. If the DiscriminatorType is STRING, the discriminator value default is the entity name.
Let us define Application.java having a main method inside it to run the example and see the entries it created in the DBApplication.java
If you run above class a java application, then you can see entries created in the DB. Since, we did not define any specific value for DTYPE column in Employee.java, by default hibernate named it as entity class name.
Simplest to implement.
Only one table to deal with.
Performance wise better than all strategies because no joins or sub-selects need to be performed.
Most of the column of table are nullable so the NOT NULL constraint cannot be applied.
Tables are not normalized.
In case of table per class strategy, there are no. of tables created equivalent to exact no. of concrete entites defined in the inheritance hierachy. Hence, in our case there will be 3 different table created and each child table contains duplicate data of its parent. Hence, this strategy is not recommended. Let us redefine the same entities to accomodate table per class strategy.Employee.java
In this case there no need for the discriminator column because all entity has own table. In this strategy you use one table per class and each one has an ID. Hence, the generation type auto does not work here.
The Application.java remains unchanged. Run this class as a java application and check the entries created in DB as per table per class strategy.
You can define NOT NULL constraints on the table.
Tables are not normalized.
Select statements require more time to execute as UNION operation is applied.
In this strategy, all the entries in the DB will be created in one table that is corresponding table of parent entity and the tables corresponding to the child entities will have reference to it. If this confuses you, then let us define our entities first and see the DB structure quickly to understand better.Employee.java
The only change in the entity definition here is the type of strategy defined in
The Application.java remains unchanged. Run this class as a java application and check the entries created in DB.
Tables are normalized.
You can define NOT NULL constraints.
Low performance as it runs OUTER JOIN as well as INNER JOIN in select stements.
I hope this article served you whatever you were looking for. If you have anything that you want to add or share then please share it below in the comment section.
Is this page helpful to you? Please give us your feedback below. We would love to hear your thoughts on these articles, it will help us improve further our learning process.
©2017, DevGlan. All Rights Reserved.
Contact us: firstname.lastname@example.org