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.