On Wed, 30 Jul 2008, Tim Spalding wrote:

> I'd consider teaching them how to use SQL directly.
>
> I've done it at LibraryThing. I take employees from the simplest
> SELECTs all the way to a people-who-have-X-also-have-Y self-join in
> one long hands-on lesson. It doubles as a sort of test, and I've even
> used it in hiring. LibraryThing's two full-time librarians got there
> with flying colors; I've had programmers who stumbled. (Not
> surprisingly they didn't work out.) Once someone understands SQL
> itself, you can throw a helper, like PMA, at them too.
>
> I think there's a real opportunity for empowerment here. Teach a man
> to SELECT and he'll never have to, um, fish again.

This might be okay with SELECT*, but I'm not so sure about giving users 
unfamiliar with SQL access to DELETE and UPDATE, which seemed to be part 
of the original request.  All it takes is one user forgetting a WHERE 
clause or mixing up a column as part of a <> condition, and the UPDATE 
corrupts the whole system.

Hell, I've even done it myself.

And I've found out the hard way that using MS Access to access MySQL via 
ODBC that the 'queries' are NOT materialized views, as I had been informed 
by my boss, and had to recover from the previous night's backup and 
manually apply all of that day's records.

...

* SELECT isn't always safe, either.  When they're badly written (use the 
wrong indices or the wrong type of join) they can start causing 
performance issues for everything else using the database as they consume 
cpu and memory or cause unnecessary disk IO.

-----
Joe Hourcle