Should you avoid object inheritence when persisting to an RDBMS solution

Question

While looking at this question: Why all the Active Record hate? I found myself thinking of a general theme that ActiveRecord pattern is good when you have little or no inheritence in your objects, and DataMapper, while more complex, works much better if you do.

Given that its never possible to perfectly match objects to relational databases, and that we don't have a really viable object database available, is it worth going to extra effort to avoid inheritence in our designs? This would allow the use of simpler solutions, like ActiveRecord, whilst avoiding their limitations.

Answer 1

There is no need to avoid object inheritance in general. There are three well-known patterns to map object inheritance to database tables (one table per hierachy, one table per concrete class, one table per class). Each has a different degree of normalization. What works and what not depends on the actual object to map. When you have an abstract base class for primary key and maybe version properties, the table-per-concrete-class pattern makes the most sense.

Answer 2

I say no, but then again I'm a fan of the object paradigm. Inheritance is a very useful technique to avoid code duplication and build an easily understandible model. I'm prepared to do the extra effort required to cram it all into an RDBMS.