I saw the section on page 50 of the JPA 2.0 spec you are referring to. Quoted below for other readers:
<quote> Support for the table per concrete class inheritance mapping strategy is optional in this release. [Note to reviewers] We would welcome feedback as to the whether support for this mapping strategy should be required. Support for the combination of inheritance strategies </quote> For my current project, I have decided to go with the JOINED inheritance type. This decision is due to the what I think of as incompleteness of the TABLE_PER_CLASS approach. I my opinion, any inheritance strategy must support the basic capabilities 1) Save a deep inheritance or polymorphic model 2) Load an inheritance or polymorphic model 2a) Directly when the type is known (id and type are known) 2b) Determine the type when the type is not known (just id is known) Everything else is a performance and/or storage optimization consideration, and this is typically where coders and DBA/data modelers get into trouble. One could also argue that 2a and 2b are performance related also, but they are tied to the mechanisms of the language. This is where the impedance mismatch between objects and relational tables lives. The classic old debate happens here and guides the design. Most people select a design that best matches their app's needs. It isn't cookie cutter, however there are established best practices which JPA is trying to capitalize on. I definitely don't think that TABLE_PER_CLASS should be dropped from the spec. It represents a valid approach for some apps, especially when join performance chokes your app. I think that capability 2b above needs to be implemented as part (or optionally) of the approach. The trade offs are 1. Performance: Joins for unions (JOINED or TABLE_PER_CLASS) 2. Performance: Join queries vs multiple non-join queries 3. Performance: Searching for a type when the type is unknown - multiple queries vs one query to find the type corresponding to the entity id ( TABLE_PER_CLASS is incomplete) 4. Storage: Sparse tables for normalized tables (SINGLE_TABLE vs (JOINED or TABLE_PER_CLASS))
