Re: Navigation question

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

If we retrive data about a customer and there is an attribute of homeAddress whose value is a foreign key to the Address table and we do not retrieve the customer and the address together (in a view), would it be accurate to say that we get the customer data and then navigate to the address data?

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

Because I could see that the fact that each query could be launched in this case from the input of a customer id by a user, for example, without caring which came first, I am adjusting the example to the one above, where we do not have the address foreign key value until we read the customer information. I can see now that they are different cases.

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

But it does in the case of navigating to the address data from the customer data, correct?

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

I can conceptually be on node A, sorry not to make that clear.

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

But there is when there is an ordering to multiple SQL queries.

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

Is it back in play with my new example?

> > When people are talking about "navigation" do they mean "iteration"?
>
> Among other things, yes.

Hmmm. How odd. Please do not confuse the two when I am talking about "navigation" since I am not implying iteration in my use of the term, OK?

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

Again, quite a different perspective, so I will have to think about that. Currently in one of my tools, I specify a logical path from one table to another (effectively a foreign key) and then when I request information about the "first" table, I can also retrieve any data from one that can be "reached" through the first table. So the coding I do is entirely declarative and yet when I choose attributes from a second "table" I think conceptually of navigating there to grab that data too. So in my use of the term, declarations and navigation can easily co-exist. Maybe there is another term for that which I have always referred to as "navigation"?

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

I was asking more broadly than just SQL, but I agree that a single SQL query would not be considered 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.

I must have mentioned SQL somewhere, so please strike whatever I said in that regard as I was speaking about software in general, which typically includes more than just SQL. I'm not asking if a single SQL statement is considered navigation, even if there is navigation under the covers.

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

Good.

> 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

Yes, that is what I am thinking about. I have not seen any applications that execute exactly one or even only (unordered) sets of SQL statements, but rather have seen SQL statements that must be done in order since data from the result of one is used to then navigate to another "place" in the database. Thanks for helping me revise my example. Since this new example still looks like navigation to me, both conceptually and logically, please advise and correct. Thanks. --dawn Received on Wed Feb 14 2007 - 22:59:21 CET