Re: Canonical DB

From: mAsterdam <>
Date: Fri, 23 Jun 2006 11:55:36 +0200
Message-ID: <449bba07$0$31648$>

Robert Martin wrote:

> mAsterdam said:

>> Robert Martin wrote:
>>> mAsterdam said:
>>>> ... "Which (or which types of)
>>>> computations are easier [with a
>>>> navigational structure]?"
>>> Things like tree searches, graph walks, etc.
>> No, tree searches and graph walks are things
>> you *need* to do (and specify) when all you have
>> is navigational structures. They are part of their cost.
> Uh... So in RM there just *aren't* graphs or trees?

Not as an element or basic construct
(not sure I got the question right).

Googling for 'graphs RM' gives ;-), substituting 'relational' for 'RM' made me stumble on

If you don't mind getting your hands dirty: mentions some Oracle specifics, in Vadim Tropashko discusses two ways "to model a tree in the database". His new book might be on the way to the stores by now, but I did not find a reference. Joe Celko wrote

>> Now where is the benefit - what are you computing:
>> Which (or which types of) computations are easier
>> with a navigational structure?
> The cheapest path between two nodes through a network graph?

Strange. You construct a navigational thing, a network graph (from what, BTW?), you suggest a problem which is only defined within the context of this construct and you say it easier to compute it with a navigational structure.


This is awfully close to:
Q. "Which (or which types of) computations are easier with a navigational structure?"
A. Those which are easier with a navigational structure.

Do you think the question is not of interest?

>> Until it becomes clear what "the canonical DB"
>> is, and the way and timing to get there
>> explicit, I'll maintain my opposition.
>> "This [asymmetric navigational structure]
>> comes close to first come, first serve.
>> If a new idea is sound at some abstract
>> level it still has to be cost-evaluated
>> against (and possibly rejected just
>> because of) the navigations in place."
Received on Fri Jun 23 2006 - 11:55:36 CEST

Original text of this message