Re: database design method

Jan,

> >OK, I get the picture. But to me it looks like you
> >are trying to undermind the original power of the RM
> >by somehow introducing new kinds of data dependencies,
> >i.e. entities not identified by value but by "position".
>
> No, in fact, that is exactly the problem. If the nodes or subtrees are
> identified by position then I could easily model it in the flat relational
> model. But in the examples I gave they are true values and identified by
> their components.

They are - in your approach - in fact identified by their parents values.
I think that kind of modeling of trees is a disaster. How do you search for nodes that - say - have the value 'x' in some attribute. Let's be concrete: if you are saving an XML-tree as you have proposed, how do you search for all elements with element type = 'person'?
Do you need a do-while loop for that??

What's wrong with the 'traditional' way, say

create table node
  (nodeID int primary key,
   blah blah...
  );

create table edge

   (parentNodeID int references node,
    childNodeId int primary key references node,     childOrder int,
    unique(parentNodeId, childOrder );

This requires recursive support (available in DB2, and partly Oracle)

(Needless to say: Dataphor has it)

Or, you can take a look at

"On Accelerating XPath Evaluation in Any RDBMS"

http://www.google.com/url?sa=U&start=1&q=http://wwwhome.cs.utwente.nl/~keulen/onderzoek/XPathAccel/tods2002_xpath-accel.pdf&e=747

for an approach that works on _any_ (SQL)-database.

>
> >What use are my powerfull relational operators if I have to write
> >a program to navigate the structure?
>
> All you need is a while-loop or recursion and Tutorial-D has that.

But I want to use my RELATIONAL OPERATORS!! I don't want to use any stupid loops! They are hard to write and the optimizer won't understand them anyway.

>
> >Anyway, whats so frightening about artificial node identifiers?
>
> Not much, the usual arguments are that they don't have "business meaning"
> and they make it necessary to add explicit other key constraints to indicate
> the "real identifier" and in this case you also need extra explicit
> constraints to indicate that they form a tree. So if we can easily avoid
> them by extending the data model a little I think we should.

This is shooting with a canon to kill a fly!

regards,
Lauri Pietarinen Received on Mon Nov 11 2002 - 21:36:23 CET