Re: Navigation question
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 20 Feb 2007 04:05:44 GMT
Message-ID: <ssuCh.8562$R71.132339_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> I'm concerned that everything that follows this promising statement
> neglects that analogy though.
>
>
>
>
> Given that RM is not navigable this sentence makes no sense. If you
> are asking why is declaration better than navigation, well thats a
> whole different issue.
>
>
>
>
> There is no travel through a relational database.
>
>
>
>
> Neither, no navigation involved.
>
>
>
>
> Thats the physical level, not the logical level.
>
>
>
>
> Correct. The user is absolutely not navigating. There is nothing to
> navigate. He is however seeing consecutive results of consecutive
> queries.
>
> If I have a photo album and someone asks for me to pick out pictures
> of dogs, then pictures of them, then pictures which are 7x5", they are
> not navigating (...thats the RM approach). If they say first picture,
> go down a picture, two pages forward, etc, then they are navigating
> (.. the network approach).
>
>
>
>
> In light of my previous comments you can see that it is not
> navigating.
>
>
>
>
> nope, still not navigating :)
>
>
>
>
> It uses a dot operator to travel down a pointer, so it is navigating
> there, agreed.
>
>
>
>
> ?
>
>
>
>
> Well if we are agreed that RM isn't navigated, then (and only then!)
> would I be drawn into my opinions on the theoretical reasons as to why
> declaration is preferable to navigation.
Date: Tue, 20 Feb 2007 04:05:44 GMT
Message-ID: <ssuCh.8562$R71.132339_at_ursa-nb00s0.nbnet.nb.ca>
JOG wrote:
> On Feb 19, 10:07 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>>On Feb 19, 3:09 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote: >> >> >>>Ok, lets fix this confusion once and for all Dawn. This one /cannot/ >>>go wrong. I have every faith that this coming analogy will clear >>>things up. No siree. Cannot fail. >> >>>* Ok, consider a Declarative programming language. Say lisp (or >>>Haskell, etc): >>>* Obviously noone would say such a language is procedural - it just >>>declares... and thats it. >>>* /However/ if one had a system was configured such that given some >>>user input, a different lisp program was fired up... well would that >>>mean that lisp was now procedural? Of course not. >>>* Thats how clear the separation in layers is. >> >>I'm tempted to accept your analogy and will come close to doing so.
>
>
> I'm concerned that everything that follows this promising statement
> neglects that analogy though.
>
>
>>However, my understanding of the aversion to navigation is that it is >>a problem with navigating "through a database" rather than strictly >>within some piece of code.
>
>
> Given that RM is not navigable this sentence makes no sense. If you
> are asking why is declaration better than navigation, well thats a
> whole different issue.
>
>
>>I will accept that just because there was >>some travel through a database does not mean that the code did so on >>its own with no intervening events.
>
>
> There is no travel through a relational database.
>
>
>>You may choose not to call this >>database navigation or choose to indicate that this pattern >>constitutes acceptable database navigation.
>
>
> Neither, no navigation involved.
>
>
>>Additionally, I will >>accept that the code might not be navigating (I didn't say that it >>did) even if database navigation occurs, analogous to your example. >>Similarly, the software in your analogy does do sequential processing, >>even if the code is declarative.
>
>
> Thats the physical level, not the logical level.
>
>
>>>Its clear the 'navigation' began before the lisp program started. Its >>>the exact same pattern when we query databases declaratively - >>>navigation just doesn't happen, never, not a sausage at the logical >>>layer. In theory. >> >>So, if the software reads through the database from company to orders >>to line items to products based on the user moving through data, you >>would not say that the software navigates through the database, even >>if it is clear that the software product permits the user to do so.
>
>
> Correct. The user is absolutely not navigating. There is nothing to
> navigate. He is however seeing consecutive results of consecutive
> queries.
>
> If I have a photo album and someone asks for me to pick out pictures
> of dogs, then pictures of them, then pictures which are 7x5", they are
> not navigating (...thats the RM approach). If they say first picture,
> go down a picture, two pages forward, etc, then they are navigating
> (.. the network approach).
>
>
>>I'm OK with that. >> >>So, the subsequent question is whether it is always wrong or poor >>practice for the software to perform similar steps, but without the >>user events between them? In that case the software would be >>navigating, right?
>
>
> In light of my previous comments you can see that it is not
> navigating.
>
>
>>And the second question of whether it is OK for the DBMS to navigate >>based on user specifications of "links" (aka join information) in the >>case of a statement such as
>
>
> nope, still not navigating :)
>
>
>>select customerid, customerName, emailAddresses, classifiers, >>Order.orderid, Order.orderPrice from Customers where tin = 'xyz' >> >>This is similar to an SQL statement that would get the same data, but >>with these differences: >>1. The DBMS navigates (do you agree?)
>
>
> It uses a dot operator to travel down a pointer, so it is navigating
> there, agreed.
>
>
>>2. There is no cross-product if the above statement returns a single >>row for this single customer, but with more complex attribute values >>(including two sets for emailAddresses and classifiers and a table for >>the order information).
>
>
> ?
>
>
>>It should be clear that there is a benefit to this approach (with 2), >>but the cost in this case is navigation. What is the downside of this >>type of navigation? Thanks. --dawn
>
>
> Well if we are agreed that RM isn't navigated, then (and only then!)
> would I be drawn into my opinions on the theoretical reasons as to why
> declaration is preferable to navigation.
Jim, please stop feeding the troll. Received on Tue Feb 20 2007 - 05:05:44 CET