Re: Canonical DB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 22 Jun 2006 01:47:03 +0200
Message-ID: <4499d9ed$0$31646$e4fe514c@news.xs4all.nl>

Robert Martin wrote:

> mAsterdam said:

>> Robert Martin wrote:
>>> mAsterdam, parafrasing Robert Martin, said:
>>>
>>>> "Applications should not strongly
>>>> depend on a navigational format unless that
>>>> format IS the most convenient form for them.":
>>>> a matter of convenience for some applications
>>>> at the cost of convenience for other applications.
>>>
>>> And so each application programmer needs to decide
>>> what form the data is most convient in, and convert from the
>>> canonical DB form to that convenient form.
>>
>> This only raises new nuances to my original
>> questions about your statements.
>>
>> "the canonical DB" is what, and gets designed how?
>> When? To start by converting from it the DB design
>> must be finished before the application design
>> starts - is that part of your method(ology)?

> 
> I was thinking of a mature enterprise system that has a well worn RM 
> holding the enterprise data, and a constantly changing set of 
> applications that use that data.

Well designed databases do not spring into existence, let alone into enterprise maturity ...

> If I were starting a system from scratch I would grow the RM and a few > applications concurrently, evolving them together.

... and they don't grow on trees (or any other graphs).

>> You snipped my original questions.
>> I'll re-state them in the current context this time:
>>
>> Earlier you said:
>>
>> "Because it [asymmetric navigational structure]
>> also makes some computations easier."
>>
>> And I asked "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.

Now where is the benefit - what are you computing: Which (or which types of) computations are easier with a navigational structure?

You claimed some are.

Is my English not good enough?
Is the question not clear?
Is the answer unwanted?

>> Also you said:
>> "An application will often reform data into a
>> non-relational structure that eases computation."
>>
>> In order to clearly understand what you meant by that,
>> I asked: '"non-relational" as a synonym to "navigational"
>> or did you have something else in mind?'
>
> The term "navigational" doesn't mean a lot to me.

The trees you search and the graphs you walk are fine examples. What of "navigational" has no meaning to you?

> I'm thinking of in-memory data structures managed > by the application language.

Hmm... not sure what you mean here.
The in-memory data structures really
managed by the application *language*
are invisible to the program.
Even to the programmer they are only visible when profiling and debugging.

The in-memory data structures
managed by the application *program*
(through the use of some language)
are visible.

It is easier to specify what to get
than to specify what to get plus
explaining how to get to where you
left it last time you used it
(needing to verify it is still there).

Why did you snip this:
>> You say "canonical" - is that to avoid one of
>> the terms non-navigational and relational?
Received on Wed Jun 21 2006 - 18:47:03 CDT