I have a class hierarchy. some new subclasses might be added in the future.

Should I use Single Table or Table per Class?

some cons/pros I can think of :

Single Table:
---------------
pros: better performance
cons: many unrelevant column are NULL. when a new subclass is added in the future, new columns will need to be added to existing table. Is it a good idea to change table schema?


Table per Class
-----------------
pros: for adding new subclasses, no changes to existing tables, no NULLs for unrelevant columns.
cons: perform not as good


which mapping strategy should I use for a class hierarchy that may add more subclasses in the future?

suggestion/comments appreciated. Thanks,

Dave

If you are planning to add more classes in the future I think that Table-per-class or joined subclass would be better options. You don't want to have to make columns NULL-able that should be NOT NULL because of the way you've done the O/R mapping.

IMO, joined subclass is nice if you are going to be treating the objects polymorphically in your code. Table-per-class is better if inheritence primarily just makes the Java code cleaner. If you use table-per-class and you want to find all instances across all concrete subtypes, this is a pain to do especially if you also need to have some SQL code that uses the same tables. With joined subclass it is easy because every entity has a record in the base table.

Joined-subclass does introduce some extra load on the database because of the join but if it's just 1 join it's probably not going to be a big deal. I have seen quite large tables work fine with the joined subclass strategy.

Of course one of the nice things about using Hibernate is that you can change your mind pretty easily. You won't have to rewrite all your queries if you swtich from one strategy to the other.

Thanks.

The class hierarchy in my case may have 3 - 5 levels in depth. I am concerned about the performance if using JOINED. The nice thing about Table-per-class is that I can see all properties of a class in a table, and it may perform better than JOINED because of fewer joins.

For table-per-class, To find all instances of a class hierarchy,
EJB QL : select * from base-class.

this will involve:

Union(all tables) order by id

For JOINED, to find all instances of a class hierarchy,
EJB QL: select * from base-class.

this will involve:

select * from base-table joined with all other tables

For treating class hierarchy polymorphically, why JOINED is better than Table-per-class? Thanks.!

You have to join to get the complete objects, but you can find the Ids (and types) of all the objects and query on shared properties with just the base table. You can load proxies to the objects without doing the joins, then execute the joins to fetch the properties on demand.

For JOINED, we can not tell row class type by looking at base table, right? because there is no discriminatorColumn as SINGLE_TABLE does. For a specific instance with id, we need to look for the id in other tables to find out its class type. This seems very unefficient. I do not know how Hibernate does it like in em.find(base-class-type, id).