I remember a post by its author where he stated that PHPLIB::DB was never designed as an abstraction layer but rather as a wrapper around
And now we are at the point of different definitions of an
abstraction layer. I see it as a "lightweight" abstraction
layer, fast, KISS and not fat.
I think a component system might be nice -- have light uniform API classes and then additional components / tools to handle the real abstraction stuff. Kinda like MDB currently breaks out the "Manager" classes. I think it would also make sense to break out the metadata classes. Personally I really like the JDBC model, and myself have been doing some work on a JDBC-like Uniform API for PHP5/ZE2 (some prelim info at http://creole.ws).
There are also a lot of convenience functions that maybe really don't need to be in the core uniform API class. Things like getOne(), getAll(), etc. (which I myself use quite frequently) should maybe be in an optional component -- so that the core classes can be kept smaller.
ADOdb is very efficient primarily because abstraction is kept to a minimum -- i.e. the adodb methods called immediately call the native PHP function (e.g. $rs->MoveNext() calls mysql_fetch_array() immediately); this isn't the case (IIRC) w/ the DB:: or MDB:: methods used by the [ADOdb] benchmarks. More generally, I simply think that ADOdb is a demonstration of the performance vs. architecture quality trade-off.
Cheers,
Hans