...
In the left ("IS A") diagram we see that the object someEmployee is an Employee which in turn "is a" (subclass of) Person. It is possible to store the same attributes of an Employee without inheriting from Person, however, by making a separate instance of Person and putting a reference to it into someEmployee. In the right diagram we see that "HAS A"-relationship. This is essentially what class table inheritance does to inheritance behind the scenes: spreading a single "instance" over several instances and establishing references between them. This is very economical in terms of redundancy, but clumsy in terms of speed and programmer convenience. After all, the query for assembling all instance data is complicated by JOINs.
As you see, the three approaches to object-relational mapping must make compromises between minimizing space or minimizing complications. Which approach is actually used in a re-motion application must be decided by a developer after taking into account how the data is used (but be aware that class table inheritance is not supported by re-motion yet). In practice a mixture between class table inheritance and concrete table inheritance is used. Before we turn to discussing how such decisions are made for a given domain, here is a recap of the advantages and disadvantages of the three table inheritance strategies in one handy grid:
table inheritance | single | concrete | class |
|---|---|---|---|
accessing instances | fast, easy | fast, easy | complicated by required JOIN |
number of columns | very high | considerably high | low |
spoilers | object members not nullable | accessing all instances, including those of common base-classes, requires UNION; table size, performance | requires JOIN |
...