Re: Do Data Models Need to built on a Mathematical Concept?

From: Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com>
Date: Sat, 03 May 2003 21:19:16 +0300
Message-ID: <3EB40824.8010409_at_atbusiness.com>


Neo wrote:

>Yes, the data can be represented by generic modelling meaning
>everything in one table. But consider that each dot may represent
>different kinds/types of things (persons, airplanes, colors, jobs,
>chairs, etc). IMO, the rdb data model is not well suited for this type
>of problem.
>
I get your point. Basically you have to make the choice where you want your application logic and rules
to reside: Do you want them in the schema or do you want it in your programs. In practice
they are devided between the two.

Putting more intelligence into the schema, i.e. creating the the tables 'persons', 'airplanes', 'colors' etc
and defining the relationships between them with associative tables or otherwise means that
you will have an easy time making (SQL-) queries against this data  (because there are rules in
the schema), and, if we had updatable views, also updating would be a flash.

In the other end of the spectrum you can have a completely generic schema, e.g. something like (very crude example, I hope you get the picture),

create table entities(entity_id)
create table relationships(entity1_id, entity2_id); create table attributes (entity_id, value)

you can save basically anything you want, but you will lose the ease of quering.
Your appication (or user) will have to have more rules in it so that it can make
sense of the data in the schema.

So basically there is no free lunch. If you want to have an automatic system
you have to have rules *somewhere*. Putting the rules into the database makes
the rules more transparent and easier to see. It also enables certain kinds of optimisations that are not possible if the rules are written into programs.

regards,
Lauri Pietarinen Received on Sat May 03 2003 - 20:19:16 CEST

Original text of this message