Re: Navigation question

From: Marshall <>
Date: 14 Feb 2007 13:32:17 -0800
Message-ID: <>

On Feb 14, 12:10 pm, "dawn" <> wrote:
> On Feb 14, 1:47 pm, "Marshall" <> wrote:
> > Or you could do this:
> > select * from orders where date > '2006-01-01' and status =
> > 'fulfilled' and customerid = 1234
> > You say what you want and you get just that. No sifting
> > through stuff you don't want; no navigating.
> OK, I was calling that "navigating." In this case, I had information
> about a customer, retrieved that customer data, then navigated to the
> orders for that customer.

No; the SQL is a single atomic statement; it doesn't have any time- or sequence-related semantics to it at all; you cannot properly use "then" in describing what it does. Try instead: "I asked for information about a customer AND about its orders AND only those order where ..." You don't say what comes first or second; you don't say how to effect the query; you only say what you want and you get only that.

The engine does something navigational under the covers, but that has nothing to do with how you talk to the engine.

> > > Do large, production-quality, highly usable and useful, data-based,
> > > read-and-write software applications actually exist where there is no
> > > code in the software that navigates around the database?
> > Sure! They tend to perform well, too, in a multitier environment.
> > All that navigation is *expensive* in terms of network requests.
> It seems that my understanding of "navigation" is not the same as
> yours.

> If I am *** on node A ***

[emphasis added]

You cannot be "on" node A in SQL. (Okay, maybe with cursors, but those are unnecessary and nonrelational.)

> and *** then ***

There is no "then" in a SQL query. (As per above.)

> ... I use information from that node to
> "navigate" to data on other nodes, I was calling that navigation.

This rest of the sentence is invalidated by the above problems.

> When people are talking about "navigation" do they mean "iteration"?

Among other things, yes.

> > The best way to do
> > that is to have the highest-level, most declarative way of
> > describing what a request wants to do.
> Are "navigation" and "declaration" mutually exclusive?

Hmmm. Maybe so.

> > A low-level navigational
> > approach will always generate a lot of individual requests,
> > because the client has to issue a lot of requests to navigate
> > through and filter a lot of data.
> Yes, and I was not suggesting that at all. I was suggesting that one
> "navigates" from node(s) to node(s), using data from one node to know
> where to head next. I hate to request a definition as some don't like
> them, but I am clearly not understanding what "navigation" means. If
> one moves from one web page to another via a hyperlink, that would be
> navigating, right?

Yes, and that's not what SQL does, so we don't call queries navigation.

> If a user moves from a node with data about one
> Person to a node about that Person's mother, that would be navigating,
> right?

Yes, and that's not what SQL does, so we don't call it navigating.

> Isn't that done in software applications all the time?

Sure. But not in SQL.

> Is it
> when there is a 1-M relationship where you pull up a set related to
> one node that it is not called navigating?

No, relationship cardinality doesn't affect it.

Maybe something to think about is the inherently sequential nature of the sort of code you're talking about above ("start on A and then move to B") vs. the inherently nonsequential, inherently atomic nature of a SQL query.

Marshall Received on Wed Feb 14 2007 - 22:32:17 CET

Original text of this message