We deliberately haven’t talked much about inheritance mapping so far. Mapping a hierarchy of classes to tables can be a complex issue, and we present various strategies in this chapter.
A basic strategy for mapping classes to database tables might be “one table for every entity persistent class.” This approach sounds simple enough and indeed works well, until we encounter inheritance.
Inheritance is such a visible structural mismatch between the object-oriented and relational worlds because object-oriented systems model both is a and has a relationships. SQL-based models provide only has a relationships; SQL database management systems don’t support type inheritance—and even when it’s available, it’s usually proprietary or incomplete.
There are four different strategies for representing an inheritance hierarchy:
- Use one table per concrete class and default runtime polymorphic behavior.
- Use one table per concrete class but discard polymorphism and inheritance relationships completely from the SQL schema. Use SQL UNION queries for runtime polymorphic behavior.
- Use one table per class hierarchy: enable polymorphism by denormalizing the SQL schema and relying on row-based discrimination to determine super/subtypes.
- Use one table per subclass: represent is a (inheritance) relationships as has a (foreign key) relationships, and use SQL JOIN operations.