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 > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
