Re: Which Database Abstraction Layer ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hans Lellelid wrote:

You definitely should do your own benchmarks. Bear in mind that the ADOdb benchmarks test a certain type of behavior -- namely repeated select statements. Also bear in mind that the speeds of the different layers are going to be inversely proportional to how well they actually /abstract/ stuff. For example, ADOdb would completely fail to be portable accross databases where the case of the column names in result array changes (e.g. postgres always returns lowercase col names, Oracle always uppercase, MySQL returns mixed case, SQLite is configurable). This is one example of why some layers (like PEAR::[M]DB) may be slower.

So you start with ADOdb datadict and build the database from that - works well when adding any supported engine. Reserved words which differ between engines are another problem area though.


Database abstraction is a really tricky thing. None of these layers provide 100% abstraction; that can only really be achieved with a DAO/object persistence layer (e.g. see DB_DataObject in PEAR, or Propel http://propel.phpdb.org).

Usual problem is adjusting non-standard MySQL SQL back to SQL99 or 2003, but each engine has it's own 'style' :)


I would also suggest you also add Creole (http://creole.phpdb.org) to your test list if you are considering abstraction layers for PHP5.

Doesn't do Firebird yet ;) - but it looks interesting. As long as it has not made the mistake of using MySQL as the SQL standard. Many other packages are simply MySQL wrappers with cobbled support for a couple of other engines.


--
Lester Caine
-----------------------------
L.S.Caine Electronic Services

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux