Re: Navigation question

From: JOG <jog_at_cs.nott.ac.uk>
Date: 19 Feb 2007 17:42:31 -0800
Message-ID: <1171935751.128667.225260_at_v45g2000cwv.googlegroups.com>


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. Received on Tue Feb 20 2007 - 02:42:31 CET

Original text of this message