Re: database design method

From: Lauri Pietarinen <>
Date: 11 Nov 2002 12:36:23 -0800
Message-ID: <>


> >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"

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!

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

Original text of this message