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
