> > Define "understand SQL".  I can't help but be concerned about the adage
> > "knows just enough to be dangerous".  I've seen some systems brought to
> > their knees in terms of performance as a result of a couple of poorly
> > constructed queries.

The irony is that it's easy to do this in some simplified SQL database
interfaces. (I know, I've done it.) Having gone through the
baby-interface-graduate-to-real-thing process, all I can say for the
starter interfaces is that they make it a tinier bit easier to construct
some very basic queries, but quickly get frustrating, particularly if
you're trying to figure out *why* you brought a system (even a test
system) to its knees. These systems are generally bespoke, so you can't
crack open a book to understand their special dumbed-down language. 

The junior interface I worked with several years ago had a free-entry
box where developers pasted free-form queries more advanced than the
guided interface could support. I learned a lot from reading those
queries and tweaking them to do new things (with a copy of that fat
MySQL book in my lap as I worked). Even if I brought the (test) system
to its knees, at least I had the means to reverse-engineer my error.

Karen G. Schneider