Re: DB Abstraction - db_oo - the query builder

As a side note to this, I did another major overhall to my query builder/ simplified db access layer, db_oo - and put up a small amount of documentation, although there is a small amount of mysql dependance in there, it's not impossible to remove... http://www.akbkhome.com/Projects/db_oo%20-%20an%20object%20based%20Sql%20builder%20and%20wrapper%20for%20peardb/ It is an evolving tool, as its the base I use for a number of projects - it can build a object based data access to any mysql database within about 2 minutes...., anyway if anyone wants to start thinking through ideas about sql builders, this does have alot of the 'chore work' done. Let us know if anybody is interested - it's API is still pretty flexible.. regards alan Stig S. Bakken wrote:

On Fri, 2002-03-29 at 13:01, Daniel Lorch wrote:

Hi, I'm a bit confused about the ongoing projects aiming towards a standard for database abstraction in PHP. There is DBA [ http://php.net/dba ], PEAR DB and a project by l0t3k (and many, many more). So what is going to be "the standard" in PHP's future? I think l0t3k is working on a C based solution, but there are several reasons I'd like to see it written in PHP. PHP code could be easily extended to handle mechanisms such as - caching: only a SELECT? then read from cached file (serialized

          result set). INSERT/DELETE/UPDATE? then refresh cache.
          - safety: server1 down? ok, move to backup server2.

- redundancy: randomly spread read-only queries (SELECT) to servers in

             a cluster.
             (- extensibility (I put this in brackets, as it is only a vague idea):

For example missing features in MySQL such as subselects could be simulated by using temporary HEAP tables. This would make this abstraction layer even more powerful than accessing the database directly) Most important: this all works *transparently* to the user's script.

               A system administrator could adjust this abstraction
               layer to fit the system configuration. The users would
               just include this file in their projects and never get in
               touch with these things.
               What do you think? Am I completely wrong/fantasising/talking too much?

When speaking about database abstraction, people (including me) are often mixing different concepts, knowingly or not. The layers involved are: 1. common API 2. feature compatibility layer (easy query rewrites, type abstraction, handling slightly different usage paradigms such as mysql's auto_increment vs. real sequences, etc.) 3. query builders, schema management, etc. (basically everything that can be done by wrapping existing functions/methods or generating SQL) All database abstraction layers provide (1). Most provide (2) to a bigger or lesser extent, with Metabase going the furthest, while few provide much from (3). IMHO an efficient database abstraction layer should provide only (1) and (2). The rest like caching, server redundancy, query builders etc. can be put on top of the abstraction layer itself and maintained separately. What PHP really needs is a common C API for (1) and possibly (2) that the database extensions themselves provide. That way there would be no need for additional layers written in PHP or piggyback hacks like dbx (sorry Marc :). Come to think of it, ODBC's CLI (Call Level Interface, what ext/odbc uses) could be this common C API. - Stig