Re: database design method

Lauri Pietarinen wrote:
>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"?

Exactly. It saves you the trouble of having to specify explicitly with constraint that the nodes form trees. Also, if you want to say that two nodes represent the tree you can say T1 = T2. Now try to express that in the surrogate key simulation.

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

That is what I meant. I'm not saying that they should be possible. What I'm wondering about is if there are very good reasons to forbid them.

>>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 ;-)

Oh, nothing but respect fo these guys.

>> >What on earth could be more declarative than relational operators???
>>
>> The relational calculus.
>
>Are they not equivalent?

Yes, but the general idea is that the calculus is closer to how people actually think and does not imply so much an execution order as the algebra does.

• Jan Hidders