Inheritance in Hibernate overview
- 9th Feb 2017
- difference between table per sub class table per concrete class and table per hierarchy in hibernate Inheritance types in Hibernate What is table per Concrete class in hibernate What is table per hierarchy in hibernate What is table per subclass in hibernate Which inheritance strategy is best in hibernate
Let us understand about Inheritance in Hibernate
Inheritance is an object oriented feature which provides the power of re-usability.
The same concept of re-usability is provided in Hibernate as well.
It is one of the advantages of Hibernate when compared with JDBC.
Assume we have Parent and Child classes, we know that Child class object will have an access to Parent class
attributes as well.
In Hibernate when we save Child class object , Parent class attributes will also be saved.
Now you may get multiple questions in your mind
1. Whether parent and child class attributes are saved in the same table
2. Whether parent and child class attributes are saved in separate table
3. If they are stored in separate table, how will they be linked
Yes if you have above questions in your mind, Don’t worry you will be getting answers to these questions shortly.
Hibernate provides 3 different ways to represent the inheritance
1.Table per Hierarchy
2.Table per Concrete class
3.Table per Subclass
Let us consider the below example to discuss all the inheritance types
Table per hierarchy
In this approach, as the name suggests the entire hierarchy is mapped to a single table. I.e. All attributes of all the classes are stored in a single table.
A discriminator column is used to distinguish different classes.
Null values will be stored in the table for which there is no column applicable.
We have stored 2 permanent and 1 contract employee details in the below table
We can see NULL values are stored in Salary column for Contract employee and NULL value is stored in HourlyRate column for Permanent employees.
Table per hierarchy is not an optimized way of storing relational data as many columns will get NULL values.
In this approach Number of tables equals to one, no matter how many classes are involved.
Table per Concrete class
In this case, one table for each concrete class will be created.
All the attributes of parent class will be stored in separate table created for each concrete class.
Assuming Employee class as Abstract,we will get only these 2 tables created for concrete classes.
The main disadvantage of this approach is that parent class attrbiutes are duplicated in each subclass table.
In this approach, Number of tables equals to number of Concrete class.
Table per Subclass
In this approach, separate table is required for each class.
Each Subclass table will have only subclass specific columns by having one extra column to have a relationship with the Parent table.
Since there will be a foreign key relationship between the tables,there will not be any duplicate columns.
As shown above, columns are not duplicated as they are referenced using foreign key in each subclass table.
In this approach, Number of tables equals to number of classes.