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