Re: Navigation question

Tony D wrote:
> [what follows my comment]

Thanks so much for this post Tony D. It was absophuckinlutely great. I've quoted most of it below for truth (sorry for the top post). The point that navigation and "sequentially parameterized queries" share some of the same disadvantages is solid and illuminating.

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

Keith - Fraud 6 Received on Sat Mar 03 2007 - 15:29:30 CET