Mindscape Blog » Blog Archive » Inheritance in LightSpeed

Inheritance in LightSpeed

One of the big mismatches between the world of objects and the world of relational databases is inheritance. Object-oriented programming likes to pull common state and behaviour up into base classes so that programmers can work polymorphically with the objects and so that common implementation can be reused. The relational world doesn’t really have an equivalent — or, alternatively, it has several near-equivalents, all of which model the same general idea in different ways.

Martin Fowler’s Patterns of Enterprise Application Architecture describes these approaches in the chapter “Object-Relational Structural Patterns.” The three entries to look at are Single Table Inheritance, Class Table Inheritance and Concrete Table Inheritance.

Concrete table inheritance is, from a LightSpeed point of view, the simplest of these approaches. In concrete table inheritance, there’s a table for every (concrete) class (entity), and that table contains all the state for that entity. Of course, that’s exactly the way LightSpeed works when there’s no inheritance involved; inheritance just means that the table for the derived entity has to contain columns for the fields of the base entity as well.

You should use concrete table inheritance when:

You have objects that have some fields in common, but are more different than similar
You don’t need to load objects polymorphically in a single query
Your base class doesn’t actually have state at all — it just adds common business logic or helper methods

To use concrete table inheritance:

In hand-coded entities, you don’t need to do anything; LightSpeed’s default behaviour will work with concrete table inheritance database schemas
In the designer, select the inheritance arrow and set the Inheritance Type to ConcreteTableInheritance

Single table inheritance is LightSpeed’s way of supporting load-time polymorphism — that is, being able to materialise different kinds of object via a base class query. It means, for example, that you can query for Contribution objects, and get back ArticleContribution, VideoContribution and PhotoContribution objects as part of the result set. (Whereas with concrete table inheritance, you’d have to query for ArticleContribution, VideoContribution and PhotoContribution objects separately, though you could treat them polymorphically within your code once LightSpeed had loaded them for you.) In single table inheritance, there is a single table, named for the base class of the hierarchy, and it contains columns not only for the base class fields, but for all the types in the hierarchy. Thus the Contribution table might contain a WordCount column for articles, a Resolution column for photos and a Duration column for videos — even though these columns make no sense for the “wrong” kind of object. The table also contains a column which indicates the kind of entity a given row represents — LightSpeed calls this the discriminator.

You should use single table inheritance when:

The objects are mainly the same, but with just a few additional fields here and there
You need to load objects polymorphically in a single query

One thing to remember when we talk about loading objects polymorphically is to consider associations. Suppose you have a Member entity, and a Member is associated with their Contributions. Then Member.Contributions is effectively a query for Contribution objects; if Contribution is a base class, this will work correctly only in single table inheritance. If you want to represent Contribution entities using concrete table inheritance, then Member will need separate ArticleContributions, VideoContributions and PhotoContributions associations. This is rarely what you want, so this will often be a driver towards single table inheritance.

To use single table inheritance:

In hand-coded entities, specify the DiscriminatorAttribute on the derived class
In the designer, select the inheritance arrow and set the Inheritance Type to SingleTableInheritance (this is the default). You will also need to supply discriminator information.

Class table inheritance, like concrete table inheritance, has one table per class, but the table contains only the new fields introduced by that class. Fetching the entire entity requires joining data from across all the tables in the class’ inheritance hierarchy. LightSpeed currently doesn’t support this database pattern.

The design considerations and consequences discussed above are purely from a LightSpeed point of view. Fowler’s book provides much more information and discusses the wider design trade-offs between the possible approaches, and is well worth a read if your domain model involves an inheritance hierarchy and you’re trying to decide how to model it in your database.

Add your comments
Author icon

Posted by Ivan Towlson on 3 November 2008

4 Responses to “Inheritance in LightSpeed”

[...] Ivan Towlson details Inheritance in LightSpeed [...]
2008 November 04 - Links for today « My (almost) Daily Links Nov 4th, 2008
[...] (For more information about the two kinds of inheritance, see Inheritance in LightSpeed.) [...]
Mindscape Blog » Blog Archive » Inheritance and database synchronisation Feb 24th, 2009
[...] we’ve previously discussed, LightSpeed supports two kinds of inheritance, which we refer to as single table inheritance and concrete table inheritance. In this post, I want [...]
Mindscape Blog » Blog Archive » Getting started with inheritance in LightSpeed Mar 1st, 2009
[...] we’ve discussed before, one of the big impedance mismatches between the object and relational worlds is over inheritance. [...]
Mindscape Blog » Blog Archive » Class table inheritance in LightSpeed Apr 27th, 2010