Re: Navigation question

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 14 Feb 2007 21:46:13 GMT
Message-ID: <FqLAh.6504$R71.98212@ursa-nb00s0.nbnet.nb.ca>

Marshall wrote:

> On Feb 14, 12:10 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>

>>On Feb 14, 1:47 pm, "Marshall" <marshall.spi..._at_gmail.com> 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.

It might do something navigational. Then again, it might not. Whether it does depends on how one clusters the data.

>>>>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.

It seems Dawn's 'understanding' of any simple english word is different from the rest of the world's.

>>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.)

Why do you bother, Marshall? You know she is neither sincere nor honest.

>>... 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.

They are as different as explaining what is from explaining how.

>>>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.

She's a self-aggrandizing ignorant. Why do you waste everyone's time elevating her nonsense?

>>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.

And it is only done in applications because the computational models generally require senseless navigation.

>>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.

If she were willing and able of honest thought, you might not waste your time with the above suggestion. Sadly, she is neither willing nor able. Received on Wed Feb 14 2007 - 15:46:13 CST