> 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. >
I would disagree there. A query builder could do a lot of stuff much nicer than a DB abstraction layer could do. A query builder could make much better use of RDBMS specific features than a DB abstraction layer could. A query builder can build the query from "scratch" with all given information whereas a DB abstraction layer (unless it parses the actual query) is fairly limited. For example think queries that should work for relational and non relational databases for example. But I think a DB abstraction layer has the advantage of letting everybody leverage their knowledge of SQL and it is also much easier to develop than a query builder that is not limiting the possibilities that SQL offers. A query builder on top of a DB abstraction layer is double the overhead. But can still be a nice solution for newbies. Implementing non relation DBs can also be done at this level, but not as cleanly imho. > 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. 1) Definitely belongs into C, but currently this is what most DB abstraction layers mainly address (lack of a clean API) 2) This probably should stay userland PHP code. But it would really be cool if DB abstraction packages only needed DB specific code for stuff that needs to be emulated or where DB specifc features can be used to gain better performance etc. Again currently way too much work is done in the DB drivers and not in the common sections of the DB abstraction packages. Something which would be totally unnecessary of the API provided by PHP would be cleaner. Lukas Smith [EMAIL PROTECTED] _______________________________ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] _______________________________ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
