Re: Navigation question

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 20 Feb 2007 13:03:17 GMT
Message-ID: <pkCCh.8617$R71.133354_at_ursa-nb00s0.nbnet.nb.ca>


JOG wrote:

> On Feb 20, 4:05 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> 

>>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.
> 
> But I'm analogy a-go-go darn it. I'm developing some sort of of
> metaphor-addicton. This one was a corker:
> 
> "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 start at the
> first picture, go down a picture, two pages forward, etc, then they
> are navigating (.. the network approach)."
> 
> Feed me analogies.

Have you ever heard of Sisyphus? He was an early promoter of navigation.

http://en.wikipedia.org/wiki/Sisyphus Received on Tue Feb 20 2007 - 14:03:17 CET

Original text of this message