The pattern demonstrates a way to map all attributes occurring in an inheritance path to a single database table.
How do you map an inheritance hierarchy of classes to database tables?
The forces are identical to those discussed with the One Inheritance Tree One Table pattern.
Map the attributes of each class to a separate table. To a classes’ table add the attributes of all classes the class inherits from.
Mapping our running example to tables results in five tables - one for each class. An instance of a SalariedEmployee is represented in one of these five tables. The SalariedEmployee is mapped as follows:
Write and update performance: The mapping needs one database operation to read or write an object.
Polymorphic read performance: A polymorphic scan of all Party objects in our running example would mean visiting 5 tables. This is expensive compared to One Class One Table or One Inheritance Tree One Table.
Space consumption: The mapping offers optimal space consumption. There are no redundant attributes, not even additional synthetic OIDs in some ancestor's tables.
Maintenance cost: Inserting a new subclass means updating all polymorphic search queries. The structure of the tables remains untouched. Adding or deleting attributes of a superclass results in changes to the tables of all derived classes. This may also touch polymorhic search queries if they are static rather than dynamically generated from a dictionary. Hence the pattern needs support by generators and dynamic queries to be maintainable.
Ad-hoc queries: As the mapping generally requires accessing more than one table to perform polymorphic searches, ad-hoc queries for polymorphic search are hard to write for inexperienced users. Queries on leaf classes are trivial.
· Database load on root tables: There are no bottlenecks in tables near to the root of the inheritance hierarchy. Accessing an object exactly locks one table.
Abstract classes: Note that abstract classes are not mapped to tables.
Type identification: You need not insert any type information into the tables as the type of an object cam be derived from the table name. Since Synthetic Object Identities should contain type information anyway, it would be a waste of effort to strip the type information to gain a few bytes of table space.
See also Representing Inheritance in a Relational Database [Bro+96]. See the same thing as Class Inheritance Table at Martin Fowlers site.