Re: Navigation question

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 20 Feb 2007 21:13:58 GMT
Message-ID: <qwJCh.8858$R71.135524_at_ursa-nb00s0.nbnet.nb.ca>

Walt wrote:

> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1171997326.875046.286230_at_k78g2000cwa.googlegroups.com...
> 

>>On Feb 20, 11:57 am, "Walt" <wami..._at_verizon.net> wrote:
>>
>>>"Andy Dingley" <ding..._at_codesmiths.com> wrote in message
>>>
>>>news:1171990396.924858.28580_at_p10g2000cwp.googlegroups.com...> On 14 Feb,

> 
> 19:47, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> 


>>>>>select * from orders where date > '2006-01-01' and status =


>>>>>'fulfilled' and customerid = 1234

>>>

>>>>>You say what you want and you get just that. No sifting

>>>>>through stuff you don't want; no navigating.

>>>

>>>>Why is that good though?  Because it avoids navigation, or because it

>>>>avoids round-tripping?

>>>>IMHO it's avoiding the second thhat is the advantage here, not the

>>>>first

>>>
>>>Neither of the above. It's good because it does not require the inquirer

> 
> to
> 

>>>know about anything other than the data.
>>
>>Good, that is a common way I have heard it expressed. However, I do
>>not see how the developer needs to know less about the logical data
>>model when using JOIN statements than if using "navigation" in the
>>form of link information. It is the same information, formulated
>>differently.
>>
>>If you put everything in a single view, then the inquirer is shielded
>>from having to know the base table for each attribute, but use of such
>>views in application code does not seem all that common, especially
>>not for read/write.
>>
>>
>>>"Navigation" as commonly used around here, means following "paths"

> 
> between
> 

>>>the data. If the inquirer has to navigate, the inquirer has to know

> 
> about
> 

>>>the available paths. Not having to know that stuff is an advantage.

> 
> It's
> 

>>>an advantage for several reasons. One of them is, possibly,

> 
> performance.
> 

>>>But this isn't the big reason. The big reason is independence.
>>
>>If there were no join statements in SQL statements in application
>>code, then I could agree that this independence is accomplished. But
>>there are, so it isn't. In that case, is a join statement "just as
>>bad as" navigation from your perspective?

> 
> 
> No.
> 
> Joins create some logical data dependency.  Navigation by means other than
> the data would create physical data dependency.
> 
> At least the SQL query writer is guaranteed (barring some pathological
> cases)  physical data independence.
> 

>>>If the inquirer expresses the query in language that makes the query's
>>>results dependent on the avilability of certain navigational paths,

> 
> then a
> 

>>>modification to the data structure can render that query invalid.
>>
>>Yes.
>>
>>
>>>That's
>>>not good.
>>
>>Not good in the same way that any change to software is "not good" or
>>not good in a way that we could have avoided making a change to our
>>software altogether when the requirement changed? Some DBMS's permit
>>synonyms so that in my example we need not code in Order.orderid, but
>>could have named it simply orderid in the context of Customer (a
>>virtual field in the Customer table) so that if the data did change
>>locations, the query (which navigates the database) would be
>>
>>select customerid, ... orderid from Customer where tin='xyz';
>>
>>In this case we can see that if we change where the data are located,
>>we simply need to change the definition of orderid, the virtual field
>>in Customer. This is not an updatable view, however (within any tools
>>I have worked).
>>
>>So, I'm still not viewing this from a perspective where navigation
>>looks more problematic than joins, for example. Your take on that?
>>Thanks. --dawn
>
> You and I are using the same words, but not the same language.

Dawn is a self-aggrandizing ignorant. Please stop feeding the troll. Received on Tue Feb 20 2007 - 22:13:58 CET