Re: Navigation question

On Feb 16, 2:42 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> On Feb 16, 10:11 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
>
>
> > On Feb 16, 10:48 am, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> > > On Feb 16, 8:34 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
> > > > On Feb 16, 9:48 am, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>
> > > > Only a second to scan before heading out, but it appears that you are
> > > > still thinking I'm splitting queries and making more round trips and I
> > > > am not. Please re-read the example you gave and the one I gave. They
> > > > have the same number of queries. How many times do I have to say that
> > > > I am not, not, not, absolutely not suggesting that we do more round
> > > > trips or split queries. Can you point me to where I have apparently
> > > > mistakenly suggested such at thing? --dawn
>
> > > Would you be willing to acknowledge that in the real-world
> > > case I've described the navigational approach is vastly
> > > slower?
>
> > > Marshall
>
> > Yes, yes, absolutely, but from my perspective that has nothing to do
> > with it being "navigational" but in taking more round-trips.
>
> If navigation and iteration are independent,

they are separate concepts

> then you ought to be
> able to rewrite my navigational, iterative pseudocode into
> a style that is navigational but not iterative, and has roughly
> the same network performance as the SQL I proposed.

That does not logically follow. I am not speaking in favor of iteration, nor am I suggesting that one should always navigate. But one can navigate without iterating and, depending on your precise definition of navigation, can also iterate without navigating.

> Please either 1) do so or 2) acknowledge that iteration
> and navigation are not in fact independent.

They are separate concepts, but there certainly can be instances where neither is appropriate. There might also be cases where if you want to iterate, you will also navigate or vice versa, but that is not essential. One does not imply the other.

> Here's the problem again.
>
> In pseudocode:
>
> ccount = count of customers
> declare spend[ccount] = all zeroes
> declare max[ccount] = all zeroes
> declare item[ccount] = all zeroes
> fetch all customer ids
> for each customer c
> fetch all invoices ids for customer c
> for each invoice i
> fetch all lineitem count, cost, item for i
> for each lineitem l
> spend[c] = spend[c] + l.count * l.cost
> if (l.count > max[c])
> item[c] = l.item
> end
> end
> end
>
> Or, in sql:
>
> select c.customerid, sum(l.count*l.cost), max(l.count)
> from customers c natural join
> invoices i natural join
> lineitems l

I much prefer the SQL. I am not in favor of all navigation, but do not rule out an algorithm because it includes navigation. Additionally, I did not initially bring SQL into this (IIRC, I'm not going back to verify that) as my reason for asking the question is that I'm trying to figure out what is intrinsically wrong with a DBMS that includes "links" by which navigation takes place. So, my real interest gets back to what people here likely don't care about, that would rewrite your last query as

list customers customerid invoiceid lineitems sum(...) break.on...

the customerid and lineitems are in different "tables" but there is a "link" specific that permits the dbms to navigate to "find" all of these attributes.

> > Do you agree that navigating is not inherently a bad thing?
>
> I try not to think in terms of "good and bad." Code has attributes
> like performance characteristics, not goodness or badness.

I agree. Good. So, if navigating is useful, then fine, we don't need to have religious statements about how navigating a database is a bad thing.

> Navigation is lower-level than declaration.

The links could be declared.

> Whether a lower
> level approach is appropriate or not is situation dependent.
> In general device drivers require a very low level of thinking,
> for example.

Agreed. --dawn Received on Fri Feb 16 2007 - 22:10:41 CET