Re: Looking for a discussion about generic datamodels

<schreurs_roel_at_hotmail.com> wrote in message news:1125653973.496115.14570_at_g43g2000cwa.googlegroups.com...
> Every now and then, I come across a IT-project that stores its data in
> a generic data model. Such data models basically consist of 4 tables:
> Entities, Relations, Attributes and Values. The Entities table contains
> a record for each table in the conceptual data model, Attributes a
> record for each column, etc.

In order to appreciate the down side of this implementaion, you need to have the following experience:

Get hired as a contract database specialist, hired to generate a new set of reports, from the existing database. That's a "lightweight" project, right. After all, any idiot can use Crystal Reports, or some such thing as that.So people have high expectations that you will promptly deliver meaningful reports.

And that's your expectation too, "as soon as you can understand the data". And that's when you discover the downside to this approach.

> Invariably, the choice for such a data model is defended by the
> argumentation that new conceptual tables and columns can be added
> without modification of the data model.

And this is the strongest argument against such an approach. One could criticize this approach on a number of grounds, including but not limited to performance, but that skirts the issue.

The real issue is that the documentation of this data is informal and often unverbalized. The very flexibility that allows you to extend the universe of discourse without formally incorporating new data definitions is the biggest weakness of the approach.

If you want undocumented data, why do you want a database? Received on Thu Sep 08 2005 - 15:03:56 CEST