Walt wrote:
> "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.
She has neither the interest in nor the intellectual capacity to
understand. Please stop feeding the troll.
Received on Wed Feb 21 2007 - 09:25:05 CST
