Re: Navigation question

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

>
> 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 Received on Tue Feb 20 2007 - 19:48:46 CET