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

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news: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.

Why create 'persons', 'airplanes', 'colors' etc. as tables? 'Neo' asked you to create them as types or domains with a common supertype. The best answer is simply: One can do that with any relational dbms that supports type inheritence. Received on Sat May 03 2003 - 21:48:02 CEST