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