An advantage of using the subclass-table strategy for abstract base classes is that properties common to multiple persistent subclasses can be defined in the superclass without having to suffer the performance consequences and relational design restrictions inherent in other strategies (which we will examine shortly). Persisting and modifying instances of subclasses is efficient, typically only requiring a single INSERT or UPDATE statement. Loading relations to these subclasses is also efficient.

Though relations to mapped subclasses of a subclass-table class are very efficient, relations to the unmapped base class itself are equally inefficient. When the concrete subclass is not known, the related object could be in any of the subclass tables, making joins through the relation impossible. Subclasses can even use repeated primary key values, forcing the JDOR implementation to record more than just the related primary key values in the database.

This ambiguity also affects queries and identity lookups: queries against a subclass-table base class require either multiple SELECT statements (one for each mapped subclass), or a complex SQL UNION.

Note

Kodo provides metadata extensions you can use to indicate that a field declared as a relation to a base class is actually a relation to a specific subclass. These extensions often alleviate the need for mapping a relation to a subclass-table type. See Section 6.4, “Metadata Extensions”. When a relation to a subclass-table class cannot be avoided, Kodo stores either the related object's primary key values or its stringified object id. If the type uses datastore identity or has a concrete application identity class, Kodo stores the primary key values. If the type uses application identity and has an abstract identity class, Kodo must resort to storing the stringified identity object.

Here are some additional caveats to consider when using the subclass-table inheritance mapping:

When the subclass table only contains subclass state, the JDOR implementation must be able to link corresponding records in the superclass and subclass tables together to retrieve all of the persistent state for a subclass instance. You tell the JDOR implementation how to do this by nesting a join element in your inheritance element. Thus, this is often referred to as a joined inheritance strategy.

As its name implies, the join element maps a logical foreign key from the subclass table to the superclass table. It has a column attribute and nested column elements for representing the subclass table's foreign key columns. Section 15.7, “Joins” demonstrated how to use columns to map joins. Typically, the subclass table's foreign key columns are also that table's primary key columns.

	Note
	Using joined subclass tables is also called vertical inheritance mapping.

All of the classes in our model except Contract and LifetimeSubscription (not pictured) use the new-table strategy. Most of these classes are either base classes or direct subclasses of Contract, a subclass-table class. In these cases, the new-table strategy is the default. TrialSubscription, however, extends Subscription, which is itself mapped to a table. Therefore, TrialSubscription could have mapped its fields to Subscription's table.

Instead, TrialSubscription maps its declared fields to the CNTRCT.TRIAL_SUB table, and joins to the CNTRCT.SUB table for base class state. The join is made by linking the CNTRCT.TRIAL_SUB.ID foreign key column to the CNTRCT.SUB.ID primary key column. The example below shows how to represent this in mapping metadata.

<class name="TrialSubscription" table="CNTRCT.TRIAL_SUB">
    <inheritance strategy="new-table">
       <join>
           <column name="ID" target="CNTRCT.SUB.ID"/> 
       </join>
    </inheritance>
    ...
</class>

<class name="TrialSubscription" table="CNTRCT.TRIAL_SUB">
    <inheritance strategy="new-table">
       <join column="ID"/>
    </inheritance>
    ...
</class>

15.8.2.1.2. Disadvantages

Using multiple joined tables slows things down. Retrieving any subclass requires one or more database joins, and storing subclasses requires multiple INSERT or UPDATE statements. This is only the case when persistence operations are performed on subclasses; if most operations are performed on the least-derived persistent superclass, then this mapping is very fast.

	Note
	When executing a select against a hierarchy that uses joined subclass table inheritance, you must consider how to load subclass state. Section 5.7, “Eager Fetching” in the Reference Guide describes Kodo's options for efficient data loading.

Like the joined new-table strategy, the table-per-class new-table strategy maps a subclass to its own table. Unlike the joined strategy, however, the subclass table includes all state for an instance of the corresponding class. Thus to load a subclass instance, the JDOR implementation must only read from the subclass table; it does not need to join to superclass tables.

Suppose that our sample model's Magazine class has a subclass Tabloid. The classes are mapped using the table-per-class strategy, as in the diagram above. In a table-per-class mapping, Magazine's table MAG contains all state declared in the base Magazine class. Tabloid maps to a separate table, TABLOID. This table contains not only the state declared in the Tabloid subclass, but all the base class state from Magazine as well. Thus the TABLOID table would contain columns for isbn, title, and other Magazine fields.

<class name="Tabloid" table="TABLOID">
    <inheritance strategy="new-table"/>
    <field name="Magazine.isbn" column="ISBN"/>
    <field name="Magazine.title" column="TITLE"/>
    ...
    <field name="data" column="TAB_DATA"/>
</class>

Notice that only the lack of a join within the inheritance element differentiates a table-per-class strategy from a joined strategy. Also, notice that a table-per-class subclass explicitly re-maps all of its inherited fields into its own table.

15.8.2.2.2. Disadvantages

Polymorphic relations to a non-leaf classes in a table-per-class hierarchy have many limitations. In some ways, they are similar to relations to a subclass-table base class. When the concrete subclass is not known, the related object could be in any of the subclass tables, making joins through the relation impossible. This ambiguity also affects identity lookups and queries; these operations require multiple SQL SELECTs (one for each possible subclass), or a complex UNION.

	Note
	Section 7.8.1, “Table Per Class” in the Reference Guide describes the limitations Kodo places on table-per-class mapping.

superclass-table inheritance mapping is the fastest of all inheritance models, since it never requires a join to retrieve a persistent instance from the database. Similarly, persisting or updating a persistent instance requires only a single INSERT or UPDATE statement. Finally, relations to any class within a superclass-table inheritance hierarchy are just as efficient as relations to a base class.

The larger the inheritance model gets, the "wider" the mapped table gets, in that for every field in the entire inheritance hierarchy, a column must exist in the mapped table. This may have undesirable consequence on the database size, since a wide or deep inheritance hierarchy will result in tables with many mostly-empty columns.