Re: database design method

"Jan Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3dd1351d$1_at_news.uia.ac.be...
> >>Implementing? This is the logical level we are talking about, so a better
> >>word would be "modelling" or "representing" and it should IMO be up to the
> >>user if this is how he or she wants to represent that data that way or not
> >
> >OK, wrong usage of that word. IMO the fewer arbitrary options a user has
the
> >better.
>
> It is very difficult to judge in advance if such a choice is always and
> everywhere under all circumstances arbitrary or not. There is no data
> structure so weird or somewhere on the world there is somebody who has good
> reasons to model their data that way. And simulating it with surrogate
> identifiers means that you have to add a set of not so trivial constraints
> that guarantee that is a tree and that there are no duplicats in the sets,
> and you burden the user with computing explicitly the deep equality. The
> bottom-line is that you cannot make the complexity go away by modelling your
> data in a simpeler data model.

Agreed. As simple as possiable, but no simpler. :-)

Do you have a reference that explores the err, 'pros/cons' of recursive types? From what you have said so far, I could certainly entertain the thought that they might be a good idea.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Nov 12 2002 - 19:08:14 CET