RE: SQL Syntax

> From: jpcarr@tredegar.com
>
> You said you didn't like the "Magic" the optimizer does for you figuring
> out the access plan
> but you then say;
>
>  >I'd like to see an application request wizard that generated the
> >best possible SQL syntax for a request
>
> Wouldn't that be more "Magic"

No, because I'd be able to review it, decide which parts to use and which
not to.  Notice that I also said I'd want it to generate native code as
well, so I could do the same thing.

What I do NOT want is some SQL engine designers best guess at what I meant
when I type in some syntax that's sort of English, sort of computer, and
mostly non-intuitive.


> > In my era, our database design was dictated by its use,
>
> ah, you hit a nerve on that one.  It is my belief that in
> OUR day,  we designed DB's for OUR use OUR program, OUR everything.
> Those days are over.  It's the user's data base.  They should have
> direct access to it, and you cannot predict their ad hoc uses
> from a myriad of interfaces.  The Joins, Views should be designed
> just as much for the End User's need as it is for OUR program's
> needs.

And I still disagree.  While the data may be the user's, the database is
MINE and always will be.  I don't want the user to EVER see how I have
stored my data.  It's my job to store it, manipulate it, and get it back to
the user.  That way I can guarantee integrity.  Without that, all the user
gets is data, not information, and there is a HUGE difference.

But I guess we can agree to disagree.  It's fine line stuff anywho.  I just
wondered if people were as worried about the black box aspect of SQL, and
the answer is "some are, some aren't".  That pretty much jives with
programmer attitudes throughout the ages, even way back in the late 18th
century when I started programming <grin>.

Joe