i.Concrete Table Inheritance Pattern

  1. Motivation
    1. Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy.
  2. Summary
    1. 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 

  3. When to Use
    1. When your data based wil be access by other application directly without domain classes.
  4. Related Patterns
    1. Class Table Inheritance
    2. Single Table Inheritance
  5. Specific Considerations 
    1. Pros and Cons
      1. Pros
        1. 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. 
        2. There are no joins to do when reading the data from the concrete mappers. 
        3. Each table is accessed only when that class is accessed, which can spread the access load.
      2. Cons
        1. Primary keys can be difficult to handle. 
        2. You can't enforce database relationships to abstract classes. 
        3. 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). 
        4. If a superclass field changes, you need to change each table that has this field because the superclass fields are duplicated across the tables. 
        5. A find on the superclass forces you to check all the tables, which leads to multiple database accesses (or a weird join).
    2. Class Table Vs Single Table Vs Concrete Table Inheritance 
      1. Trio of inheritance patterns can coexist in a single hierarchy
  1. References
    1. http://martinfowler.com/eaaCatalog/concreteTableInheritance.html