Re: Navigation question

From: dawn <dawnwolthuis_at_gmail.com>
Date: 20 Feb 2007 19:14:58 -0800
Message-ID: <1172027698.109823.138620_at_a75g2000cwd.googlegroups.com>


On Feb 20, 3:09 pm, "Walt" <wami..._at_verizon.net> wrote:
> "dawn" <dawnwolth..._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.

Would this dependency be the same as if join information were specified to the DBMS? In other words, is the dependency that if additional metadata is specified (whether a link or join information), then it is one more piece of (meta)data on which we might build applications, but that could change, thereby breaking applications? If so, this could also be a reason not to store any typing metadata, or max lengths, for example. Or is there something decidedly different about this type of metadata (link or join information) that makes it such that we should not store and use such data in our applications?

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

Yes, but I'm trying to bridge the gap. It is difficult when working with multiple data models and related language. Your argument here sounds very familiar, so I would really like to fully understand it. Thanks for your assistance and patience. --dawn Received on Wed Feb 21 2007 - 04:14:58 CET

Original text of this message