Re: Navigation question
Date: 20 Feb 2007 08:19:32 -0800
Message-ID: <1171988372.903647.175190_at_t69g2000cwt.googlegroups.com>
On Feb 19, 7:42 pm, "JOG" <j..._at_cs.nott.ac.uk> 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.
It makes no sense for the RM, I agree. The RM has a philosophy against navigation, if I understand correctly. Maybe I'm not using terms correctly when I suggest that a developer could use SQL to navigate (improper as that might be) by taking data from one resultset to seed another. What I do not understand is why navigation is considered a bad thing and what navigation, precisely, is considered bad.
Is it a bad thing if a DBMS were to have the ability for one to code something like the psuedocode I indicated select customerid, customername, ... Order.orderid,... from Customer...
Where the "link" between Customer and Order is specified to the DBMS.
> If you
> are asking why is declaration better than navigation, well thats a
> whole different issue.
No, the above example is declared, but the DBMS navigates based on the specification.
> > 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.
My question is an attempt to understand why navigation is considered a bad thing. I do not care if the database is relational or not. In the case of taking a value from one resultset to seed another, it seems that the code would be navigating through the database, even if the individual SQL statements do not. In the second example of a nonRDBMS, the DBMS navigates based on the link declarations and the SQLlike statement.
> > 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.
I care little for the physical level and am not discussing physical navigation, although I beginning to think that you think that what I am calling logical navigation is actually physical.
> > > 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.
I agree, but would say that the navigation the user is doing is "conceptual navigation" and not "logical navigation" in this case.
> 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).
OOOOOh! Light Bulb goes off. You are going to hate my next statement, but the navigation in my examples is not from entity to entity, but from the "perspective" of a single entity. Your example pulls in an iteration, or at least data about more than one person (or picture), for example. Now, I'll try to redeem that statement in your eyes by trying to use terminology you might prefer, maybe, possibly. I am not looking at navigation that moves from one row to another, but from data in a single row to related data. The related data is related in such a way that an attribute value in the initial row can be used a foreign key value for another table, thereby retrieving data from that second table after the first.
> > 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.
OK, good. This would be logical navigation in my terminology as the developer does not care at all whether there is any movement from one sector to another or from one volume to another. Any physical navigation is as relevant to the above statement as it is to any SQL statements that might correspond to this statement.
> > 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).
>
> ?
I can grab all the data I want for a screen with one statement. If there are 3 emailAddresses, 5 classifiers, and 10 orders, my above pseudocode retrieves one row, with a couple of lists and a nested table in it. That is very easy to work with to get that very same data to the screen for the user. If you put that all in a single SQL statement, you would get 150 rows returned with the data, which is not as easy to work with.
> > 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.