Re: Navigation question

On Feb 18, 1:44 pm, "Walt" <wami..._at_verizon.net> wrote:
> "Tony D" <tonyisyour..._at_netscape.net> wrote in message
>
> news:1171648378.363589.27160_at_j27g2000cwj.googlegroups.com...
>
> > All this talk of "nodes", and "then", and "going to" and so on -
> > that's not what's happening. There is no "moving finger" that you
> > guide through the database from table A to table B. You are issuing
> > multiple independent queries with (hopefully) increasingly defined
> > parameters. There is no connection between them, other than some
> > shared parameters. Even in an SQL DBMS, you *cannot* "navigate" around
> > tables.
>
> It is possible to write Oracle applications that proceed in precisely this
> fashion.

No you can't (hierarchical queries and 'connect by' and friends notwithstanding).

> I have seen them. They are lousy. They deliver bad performance.
> They are hard to learn. They are difficult to modify.
>

Navigational code has all of these attributes, and more.

The bottom line is that, in an SQL database (which doesn't include hierarchical queries or connect by etc. etc. god I'm getting tired qualifying with that) you *cannot* navigate through data. What you *can* do is issue successive queries picking up parameters as you go.

What I think is being meant here is the sort of thing Dawn was pushing earlier (except that she suddenly decided that although using SQL syntax she wasn't dealing with SQL, or something). That is :

select some_value into :some_variable
from some_table
where some_column = 'some user input';

select other_value into :other_variable
from other_table
where other_column = :some_variable;

select more_data into :more_variables
from more_table
where more_column = :other_variable;

This is *not* navigation; there is no "pointer" being "moved" around the database, "directed" by some "invisible hand" in your program. Anyone who persists in this foolish notion does so at their peril. What there *is* is a succession of *discrete* *independent* queries successively parameterised based on data picked up in earlier queries. No "pointers", no "nodes", no "movement", no "going to" or "coming from". To the semi-sighted, or those not paying sufficient attention to the details, it might *look* like navigation. But it ain't.

What's wrong with this ? Well, a hard coded query plan for a starter; the data will always be selected in precisely this order, whether that's the best way to do it or not. Multiple trips back and forth to the database, if this is in a client server environment. Loads of things most of us are well aware of.

Dawn's "cross product" comes from the naive replacement for this code, in the situation where there is more than one possibility at each successive query. Remember how we said

select some_value into :some_column
from some_table
where some_column = 'some user input';

How would we deal with that, if there was more than one possible row matching the user input ? Why, iteration over the results of course ! Or, hope that there is only one row matching the user input, and if there's more than one, ignore all of them apart from whichever one comes back first. Alternatively, we could group all the queries into one query, pay attention to appropriate uses of distinct and restriction, and work with the *one result set* that comes back.

[ snippage ]

> The fact that thousands of good applications were built in the same time
> frame using Oracle, DB2, SQL Server, Postgres, and dozens of other soi
> disant "relational DBMSes" is of no consequence to Dawn. She simply
> dismisses those acheivements as "not empirical evidence".
>

I've just seen, in a completely unrelated mailing list, my favourite quote of the year :

"... But the web is a giant squeaky wheel amplifier.

Remember: the plural of 'anecdote' is not 'data'."

The poster should have the year off for that, as far as I'm concerned.

[ snips ]

• Tony (Who is now in a determinedly good mood, having awoken his MG from its slumbers. Nothing anyone can say can depress me for the rest of the day !)