Generalization - Another Gap between DB- and OO-Models

I was just reading a moderately interesting article about MUCKs (Massively Unified Code-Key tables).

Here is the article:

Lookup Table Madness

(you have to register…)

However there are two interesting thoughts in the article which I want to repeat here.

The first point is a very general statement:

Be careful that you don't generalize your database into irrelevance, building in so much flexibility that your system degenerates into chaos (chaos being the ultimate in flexibility).

This statement is certainly valid for any part of a system not just for the database. Generalization is a two edged blade and it is the characteristic of a good design to apply as much generalization as possible while keeping the model still usable.

The second point elaborates on Generalization in respect to the differences between the OO-model and the DB-model:

Generalization is a good thing, in the right context, but it is a tool and should not be used indiscriminately. Generalization is something that can be very useful in the Object Oriented (OO) programming world where you are concerned with what things do, or how they act. If two things act the same way they can be brought together under a single class. Even if they differ significantly, they might be able to inherit their common characteristics from a parent class, relying on subclasses to provide their unique behaviors. In the world of relational database design we really don't care so much about how things act, we care about what they are. In that context, generalization is very seldom useful. In the world of OO programming generalization helps improve code reuse, modularity, and maintainability. By contrast, generalization in a database leads to ambiguity, or loss of meaning.

This once more shows that there are fundamental differences between concept of a relational data store and a object oriented application. If the business logic of the application is non-trivial, the behavior of our business entities is getting very important. Generalization then is a useful instrument to introduce abstractions and therefore to reduce complexity. In the Database on the other hand we are not interested in behavior, so in most cases we don't want abstraction!

This leads us back to the good old object-relational-mismatch. And for me its another sign, that you should definitely not build your business logic around a relational model. Because sooner or later you will have the need for abstraction and your relational model will not be able to deliver this abstraction, nor can it be changed, because it is tied to the DB-schema.

Personally I believe the only real solution is to design a Domain Model for the business logic separately from the DB-schema. Ideally the two tasks are performed by different persons/teams. When both models are completed OR-Mapping is applied to bridge the gap between them. Almost certainly some compromises on both models will be necessary to make the mapping feasible, but those compromises will be made very conscious, and the different purposes of the two models will be kept intact,