We have a database with tables that use an inheritance hierarchy. An entity in the derived table will have an ID that matches an entity in the base table and so on through the hierarchy.

We have repository classes for the derived types/tables so that you can get specific instances by ID. The problem we have at the moment is that we want the ability to apply specific behaviour to some of the entities, but we also want some generic behaviour applied to all the base entities. It would be good if a client could treat a collection of entities as the base entity and just call the method to perform this action on it, without having to know about the specific behaviour.

So the client will receive from the server a collection of entities, including their ID. The client will then call a method on the server with some of those IDs and somehow the server needs to be able to tell which derived types the IDs belong to.

I considered leaving the table inheritance in place so that data isn't duplicated, but having a "type" tag in the base-table. Is this defeating the purpose of the inheritance hierarchy?


A type tag is perfectly normal. It really simplifies queries.

 select p.type, p.foo, a.bar, b.baz
 from parent p
 join child a on p.id = a.id
 join child2 b on p.id = b.id
 where p.type = 'some type'

The database doesn't have polymorphism and you will need an identifier at the global level (i.e. parent table) in order to make the transition from database to class objects

  • I suggested this, but our lead has gone with a different option. We're using the visitor pattern to get a list of different types, but unfortunately this means checking each table to see which one the entity belongs to...
    – NickL
    Dec 17 '13 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.