Re: Navigation question

"Tony D" <tonyisyourpal_at_netscape.net> wrote in message news:1171819033.570322.14180_at_k78g2000cwa.googlegroups.com...
> 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.
>

Tony,

OK, OK, if you insist that the above is *not* navigation, then I have to agree with you.

However, that's clearly not what dawn means by "navigation". I'm not sure exactly what she does mean, but that's not it.

In any event, the series of queries each one parameterised by data returned from a prior query has the effect of
treating a foreign key as though it were nothing more than the logical analogue of a pointer. In other words, "we haven't got pointers in our hands, but we do have foreign keys, so we will use the foreign keys to accomplish the same tasks, in the same way, that we would have used pointers, had we had pointers in our hands."

I'll call this use of foreign keys the "surrogate pointer usage". If you build an application using "surrogate pointer usage" to the exclusion of better ways to write queries and updates, what you end up doing is eliminating most of the advantages that Codd initially foresaw with the adoption of the relational data model, and that have been further advanced over the years by authors such as Date, and by thousands humble practitioners such as myself."

Dawn's use of SQL is a parody of the relational model. If Bob Badour is right about her insincerity, it may be an intentional parody, whose purpose is to get the rest of us tied up in knots. Received on Sun Feb 18 2007 - 23:06:45 CET