Embedded Files
Motivation
Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy.
Summary
It is similar to class table inheritance but one difference is that, only concrete class are mapped to table and all the fields of concrete classes are mapped to the table even if it causes duplicates in between tables
When to Use
When your data based wil be access by other application directly without domain classes.
Related Patterns
Class Table Inheritance
Single Table Inheritance
Specific Considerations
Pros and Cons
Pros
Each table is self-contained and has no irrelevant fields. As a result it makes good sense when used by other applications that aren't using the objects.
There are no joins to do when reading the data from the concrete mappers.
Each table is accessed only when that class is accessed, which can spread the access load.
Cons
Primary keys can be difficult to handle.
You can't enforce database relationships to abstract classes.
If the fields on the domain classes are pushed up or down the hierarchy, you have to alter the table definitions. You don't have to do as much alteration as with Class Table Inheritance (285), but you can't ignore this as you can with Single Table Inheritance (278).
If a superclass field changes, you need to change each table that has this field because the superclass fields are duplicated across the tables.
A find on the superclass forces you to check all the tables, which leads to multiple database accesses (or a weird join).
Class Table Vs Single Table Vs Concrete Table Inheritance
Trio of inheritance patterns can coexist in a single hierarchy
References
Page updated
Google Sites
Report abuse