Re: Navigation question
Date: Wed, 21 Feb 2007 15:12:18 GMT
Message-ID: <mjZCh.1030$tQ.172_at_trndny07>
"dawn" <dawnwolthuis_at_gmail.com> wrote in message
news: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
>
The best way to fully understand the argument is to find a database & application suite that used the concepts well, designed properly, and acheived success. If you can't find any such application, I suggest you look harder. Received on Wed Feb 21 2007 - 16:12:18 CET