Re: [PHP-DEV] DB Abstraction
Lukas Smith wrote: 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. This is what Apple Webobjects use: http://developer.apple.com/techpubs/webobjects/Reference/Javadoc/ This is how it looks like: http://developer.apple.com/techpubs/webobjects/GettingStartedOnWindows/Movies/index.html This is what Sun puts against Apple Webobjects: http://industry.java.sun.com/solutions/products/by_product/0,2348,all-873-99,00.html They even offer a transitional tool that converts Apple EOF into Sun ROF models. I once hacked together a quick study of a ER model representation and SQL generator in the days of PHP3. It was very slow due to object creation overhead: The ER model and access layer abstration use a great number of objects, most of which are only fired once or twice on a page. Using this to model abstract access to a database was not paying off within the deployment model of PHP. I stayed with DB_MySQL in PHPLIB and later ranted about the necessity of an Application server and truly persistent objects on this list. :-) Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] DB Abstraction
Actually a query builder is an add-on. There should be no overhead at all to the db abstraction layer. With overhead I mean you have a another object that first builds the query that in turn creates a DB abstraction layer object ... So there will be a double overhead to the query builder user. Obviously there will be no overhead to the DB abstraction layer user. Best regards, 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] ___ -Original Message- From: John Lim [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 31, 2002 6:19 AM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] DB Abstraction Hi Lukas, Bye, John Lukas Smith [EMAIL PROTECTED] wrote in message 006701c1d84c$795d5b40$4d00a8c0@vandal">news:006701c1d84c$795d5b40$4d00a8c0@vandal... 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DB Abstraction
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
RE: [PHP-DEV] DB Abstraction
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
Re: [PHP-DEV] DB Abstraction
Hi Lukas, Actually a query builder is an add-on. There should be no overhead at all to the db abstraction layer. Bye, John Lukas Smith [EMAIL PROTECTED] wrote in message 006701c1d84c$795d5b40$4d00a8c0@vandal">news:006701c1d84c$795d5b40$4d00a8c0@vandal... 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DB Abstraction
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? Daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DB Abstraction
Hi silly me, DBA [ http://php.net/dba ] [..] I meant DBX http://php.net/dbx Daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
