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@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 Mon Feb 19 2007 - 22:05:44 CST