Table Per Subclass Vs Table Per concrete class in hibernate?

25
votes

In most of the web application, i have seen one base class consisting common properties and number of subclasses extending base class . So my question here is which strategy we should go for among Table Per Subclass Vs Table Per concrete class. I personally feel we should go for table per subclass because in future if we want to introduce the common column we can do it at one place but in case of concrete class we have to do it in multiple tables. Right?

But yes if we want to fetch all deatils from all child tables i think Table per concrete class will be helpful Because we have to simply union the records from all tables but in case of Table per Sub class along with union we have to introduce the join with parent table which will be extra costlier .Right?

2
sqlhibernate

2 Answers

27
votes

You might be interested in Section 2.12 "Inheritance Mapping Strategies" of the JPA 2.0 specification, as it sums up all possbible inheritance types as well as their advantages and drawbacks. Let me pull out just the most interesting fragments:

2.12.1 Single Table per Class Hierarchy Strategy

This mapping strategy provides good support for polymorphic relationships between entities and for queries that range over the class hierarchy. It has the drawback, however, that it requires that the columns that correspond to state specific to the subclasses be nullable.

2.12.3 Table per Concrete Class Strategy

This strategy has the following drawbacks:
- It provides poor support for polymorphic relationships.
- It typically requires that SQL UNION queries (or a separate SQL query per subclass) be issued for queries that are intended to range over the class hierarchy.

2.12.2 Joined Subclass Strategy

It has the drawback that it requires that one or more join operations be performed to instantiate instances of a subclass. In deep class hierarchies, this may lead to unacceptable performance. Queries that range over the class hierarchy likewise require joins.

Also, if you're planning to be JPA-compatible, remember that the JPA-provider doesn't have to support TABLE_PER_CLASS strategy type.

I personally feel we should go for table per subclass because in future if we want to introduce the common column we can do it at one place but in case of concrete class we have to do it in multiple tables.

True, but JOINED strategy also provides you the same feature and allows to specify common properties in one table.

Hope that helps!

17
votes

The Object-Relational Impedance Mismatch

In Object Model, while creating object we may require to use inheritance i.e. Generalization as follows:

enter image description here

enter image description here

In Relational Model, the above Generalization(not association i.e. one-to-one or many-to-many) can achieve in Hibernate ORM with the following three inheritance mapping strategies:

  • Table Per Class i.e. for Hierarchy only one table
  • Table Per Concrete class i.e. One table for each concrete class not for super class
  • Table Per Subclass i.e. One table fore each class

enter image description here

In this strategy, we can map the whole hierarchy into single table, here we use one more discriminator column i.e. TYPE.

enter image description here

In this strategy, tables are created as per class but related by foreign key. So there are no duplicate columns.

enter image description here

In this strategy, tables are created as per class but related by foreign key. So there are no duplicate columns.

enter image description here

image source