Single Table Inheritance or Class Table Inheritance

Single Table Inheritance or Class Table Inheritance?

I would like to point you to a great article I have found that explains with clarity why and when to use CTI. LINK

Single Table Inheritance (Database Inheritance design options) pros and cons and in which case it used?

In my student opinion Single Table Inheritance make database more smaller vs other approaches because she use only 1 table.

Not necessarily. If the entities of your hierarchy have not much attributes in common, this will result in many null columns and will waste a lot of space.

But I read that the more favorite approach is Class Table Inheritance according Bill Karwin.

IMHO, there is no single answer, the different strategies (one table per hierarchy, one table per concrete class, one table per class) have all strengths and weaknesses and choosing one or the other depend on the context.

Single Table Inheritance pros and cons and in which case it used?

This strategy is nice when you need "polymorphic" queries (no need of joins or unions) as long as you can minimize the number of nullable columns (and convince the DBA that a denormalized schema won't be a problem in the long run).

Actually, I suggest to check Mapping Objects to Relational Databases: O/R Mapping In Detail by Scott Ambler (the author of the reference paper about ORM) and especially the section 2.6 Comparing The Strategies—there is no point in paraphrasing him.

His summary of the Single Table Strategy:

Advantages:

• Simple approach.
• Easy to add new classes, you just need to add new columns for the
  additional data.
• Supports polymorphism by simply changing the type of the row.
• Data access is fast because the data is in one table.
• Ad-hoc reporting is very easy because all of the data is found in
  one table.

Disadvantages:

• Coupling within the class hierarchy is increased because all classes are
  directly coupled to the same table. A
  change in one class can affect the
  table which can then affect the other
  classes in the hierarchy.
• Space potentially wasted in the database.
• Indicating the type becomes complex when significant overlap between types
  exists.
• Table can grow quickly for large hierarchies.

When to use:

• This is a good strategy for simple
  and/or shallow class hierarchies where
  there is little or no overlap between
  the types within the hierarchy.

But I warmly recommend to read the whole paper.

Multiple Table Inheritance vs. Single Table Inheritance in Ruby on Rails

Given the limited info, I'd say stick with STI.

The key question is: Are there places in your app where you want to consider all types of Notifications together? If so, then that's a strong sign that you want to stick with STI.

Can a single table inheritance entity extend a class table inheritance entity?

What you're trying to achieve is not possible with pure mapping.

The documentation for Class Table Inheritance and Single Table Inheritance clearly state:

The @InheritanceType, @DiscriminatorColumn and @DiscriminatorMap must
be specified on the topmost class that is part of the mapped entity
hierarchy.

You might be able to make this work by implementing a subscriber to the loadClassMetaData event that changes the inheritance-type dynamically (i.e. based on annotations on of the child entities).

Some further inspiration can be found in this article.

JPA single-table inheritance mapping and two relationships to sub classes fails with unexpected result (Hibernate )

It's a bug in all Hibernate 5.x versions.

I don’t know which HHH fixed this or if we even tagged a commit properly. We just figured that this was wrong in Hibernate 5.x so we fixed it at some point.

See here:

https://discourse.hibernate.org/t/two-relationships-to-single-table-inheritance-sub-classes-failing-with-hibernate-5-3/6012

Doctrine2: Should parent classes in single table inheritance be abstract?

As there are no methods in your parent class "Fruits" that you need to redeclare I don't think there is an explicit need for it to be declared as abstract.

Also you may find a use case where you may want an instance of "Fruit" to be persisted (undetermined as to what type of fruit it is). Marking the parent as abstract will prevent you from being able to do this.

Maybe fruit is a bad example. But the Person example they have in the documentation is better. Employees will inherit Person definitions. But I may also want to persist just an instance of Person, undetermined of type. Hence the "person" = "Person" in the @DiscriminatorMap.

http://docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/reference/inheritance-mapping.html#single-table-inheritance

Multi-table inheritance in rails

The closest built-in solution to Rails is DelegatedTypes.

With this approach, the “superclass” is a concrete class that is represented by its own table, where all the superclass attributes that are shared amongst all the “subclasses” are stored. And then each of the subclasses have their own individual tables for additional attributes that are particular to their implementation.

This is similar to what's called multi-table inheritance in Django, but instead of actual inheritance, this approach uses delegation to form the hierarchy and share responsibilities.

It was added relatively recently, in Rails 6.1 - so the results of your google searches might pre-date it.

---

Related Topics