I find your general approach for identifying the common database functions interesting, but its both annoying and disappointing that respected developers in the PHP community still consider mapping an individual table to a class a suitable practice, and promote it almost like a panacea solution.
With this method we could end up with a massive no. classes (1 per table), with the headache of performing cross table joins - the obvious solution is to execute multiple queries from the various objects till we retrieve all the details required.
But consider, proper database design promotes the seperation of data using the NF (normal form) paradigm, in the "real world" databases consist of tens to hundreds of tables, and 99% of SELECT queries perform cross table joins - So apart the very simplest of scripts and databases, this approach is bad for several reasons
1) Potentially hundreds of classes
2) Very difficult to perform cross table joins
3) Any relationships need to be hard coded in various places (rather than just within the SQL).
4) Increased complexity and execution time.
These lend to increased development, maintainance and running costs.
Instead, classes should reflect the NF relationship to describe "real world" objects, and then pull the relevant fields to fill these attributes - Using this approach will reduce the number of required classes, centralise the SQL generation, reduce the number of queries and overall be more maintainable.
I do apologise if my opinion offends, its not meant as personal critism, but this is an old idea being re-hashed for a new generation.
One new solution that does intrigrue me is the idea of SQLMaps, which maps database values to objects by the use of XML configuration files.
Unfortunately nothing similar is yet available for PHP :)