Hibernate Single Table inheritance mapping

When we have to map Java domain model based on the inheritance into relational structure persisted in database, JPA and Hibernate helps us do it in several ways. The default (when you don’t specify it exactly) and the simplest one is the SINGLE_TABLE strategy. Let’s look how we can use it, what pros and cons it gives us.

Model

Here are Java classes with JPA mappings:

 
@Entity
@Table(name = "PRODUCT")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) 
@DiscriminatorColumn(name="type") 
public class Product {
 
    @Id
    @GeneratedValue
    private Long id;
 
    private String name;
 
    //Getters and setters
} 

 
@Entity
public class Car extends Product {
    private int brand;
    private int model; 
} 

 
@Entity
public class Toy extends Product {
    private int minimalAge;
}  

As you can see, the strategy is configured in the root class of entities hierarchy, by the @Inheritance annotation. If you omit the type of the strategy, the default SINGLE_TABLE will be chosen.

@DiscriminatorColumn specifies the name of the column that is used to distinguish entity types. The annotation is optional, when not specified, the default value “DTYPE” will be used.

All the entities under the root entity don’t need any specific configuration. The only thing we can configure is the value used in the discriminator column for the entity. In this case we do this using @DiscriminatorValue annotation as follows:

@Entity
@DiscriminatorValue("Toy")
public class Toy extends Product {
    private int minimalAge;
} 

In this example “Toy” value will be inserted in the column “type”, when Toy will be persisted. Without specyfying own discriminator value,

Pros

Persisting all entities in one table gives us a good performance, when using polymorphic queries (for both writes and reads). Executing queries that operate on different levels of entities hierarchy, the query runs only on one table, without any joins. Of course, there is also better to control the table, instead if we had many tables – all defined constraints are kept in one place.

Besides, using Single Table strategy, we can use only one Primary Key generation strategy – common for all subclasses – definition of the primary key should be defined only at the root entity level.

Cons

Due to the fact we one table to store all entities, we have to allow to store null values for all fields of subclasses – we can only have not null constraints for fields in the root entity. By using Single Table strategy most of the constraints according data (all checks like ) have to be moved from the database to the application level.

When we have to persist very complicated hierarchy in one table (with most fields in subclasses), the amount of columns with null values can significantly rise. The readability of such rows can be weak.

Summary

Single Table strategy provides the best performance for writes and reads, because queries run only on one table. If we have to disable most of data integrity checks at the database level and move them to our application, the strategy can be very efficient solution.