Re: Navigation question
Date: 14 Feb 2007 13:32:17 -0800
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.
> > > 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
> and *** then ***
> ... I use information from that node to
> "navigate" to data on other nodes, I was calling that navigation.
> > 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?
> > 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,
Yes, and that's not what SQL does, so we don't call it navigating.
> 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.
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.
MarshallReceived on Wed Feb 14 2007 - 22:32:17 CET