Re: Navigation question

On 20 Feb, 16:19, "dawn" <dawnwolth..._at_gmail.com> wrote:
> 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 non-
> RDBMS, the DBMS navigates based on the link declarations and the SQL-
> like 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.
>
> RM isn't navigated (but, at the risk of you wanting to hit me,
> databases often are). That is why I'm asking such questions. There
> seems to be a mindset against any form of navigation and I am trying
> to figure out just what precisely is problematic with navigation in
> either of the two ways I have indicated. 1) programmer using a value
> from a resultset to seed another query or 2) DBMS having the
> specifications to be able to understand the logical navigation.
>
> Thanks for your patience with me. --dawn

Argghghgh. Now I am become Sisyphus, the pusher of stones. Received on Tue Feb 20 2007 - 19:45:20 CET