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 - 15:59:21 CST