Getting around "Table per Concrete Class" in Hibernate inheritance mapping strategy

Question

In my java I have a generic class (could be abstract or non-abstract either way, but does NOT map to a table in the database). It has one or more variables that are common to every class. Example:

public class GenericThing {
    private Date createDate;
    public Date getCreateDate() {
        return createDate;
    }
    public void setCreateDate(Date dt) {
        createDate = dt;
    }
}

This is useful because literally every table in the database has the column CREATE_DATE.

In this case the right inheritance strategy to use in Hibernate is "table per concrete class". But, this is "bad", they say, because each table requires that identical column and if you change that column name (CREATE_DATE) you have to change every table's column name. Well, obviously this is true, but what is the alternative? Obviously I do want every table in the database to store the Create Date, but I don't want every object in the entire database to be in one table, so that precludes (as far as I know) all the other mapping strategies, right?

Aun Aun · Accepted Answer · 2014-11-11T12:04:06

Actually for your usecase, nothing wrong in using Table per concrete class strategy

The problem you are trying to solve is not creating any redundancy at schema level(when tables are created). Even if we do the entity modelling in reverse mode, this is fine. In-fact, create_date is specific to each row for every table.

Table per concrete class is not recommended only when you are dealing normal inheritance for example User -> Customer -> Supplier where each extended class is a kind of parent class and the specific extra attributes added in the sub class need not be duplicated in the all the tables (Join Table strategy is recommended for such cases)

Getting around "Table per Concrete Class" in Hibernate inheritance mapping strategy

2 Answers