Re: database design method

Jan,

> >OK - no do-while loops. But how on earth does the optimiser handle this
> >query besides materialising the whole tree?
>
> By pushing the selection into the recursion and using a query optimization
> technique called "magic sets".
>
> >Can it use a traditional B-tree index to find Attr="Lauri"?
>
> Yes.

So this is in a sense just a short cut to tell the system "this is a tree"?

> What loss? Everything that could be done can still be done. Loss of
> optimizability? Not true; in the physical model the data might be
> represented in the same way as when the user had used surrogate identifiers?
> Loss of simplicity? That is up to the user, if he or she wants to represent
> their data that way then it is probably the simpelest for them.

Well, more stuff to implement... more bugs... On the other hand, if this really is necessary then why not. But I just got the impression that you thought that these recursive definitions were very important. Now it looks like they _might_ be useful in _some_ situations.  

> There is actually in this case a natural key: the position in the document.

True. Actually prefix and postfix orders will give the structure as well.

>
> >> >This requires recursive support (available
> >> >in DB2, and partly Oracle)
> >> >
> >> >(Needless to say: Dataphor has it)
> >>
> >> Good. So everything we need is already there.
> >
> >Sorry.
> >Not the recursive definitions, but an explode-operator.
>
> Then the claim that it has recursion is incorrect. The explode operator is
> ony a very limited form of recursion.

Sorry - a missunderstanding.

>Why does it not have recursion?

Poor guys! They have done quite a lot in 1,5 years! Don't be too harsh on them ;-)

>
> >> You can. But I don't think you should be using algebra operators for that
> >> but a more declarative type of language. I assume Dataphor has that?
> >
> >What on earth could be more declarative than relational operators???
>
> The relational calculus.

Are they not equivalent?

regards,
Lauri Pietarinen Received on Wed Nov 13 2002 - 01:02:12 CET