I really cannot make a fair comparison because I do not use ADOdb at all.
What I can tell you is that Metabase was created in late 1998. It was the first PHP database abstraction to focus on total database application portability.
This means that you can develop database applications that work with different RDBMS without changing a single line of your PHP application code. This includes both the application code that accesses the database, and also the code to setup and upgrade the database schema.
Several other PHP database abstraction packages that came after Metabase, like ADOdb, copied several of its portability features, like data type mapping, auto-incremented sequences, etc..
Other features like database schema management are not so easy to copy. Some even copied the ability to install a schema defined in a database independent XML format.
However, if you want to upgrade, all you need to do is to change the schema file and tell Metabase to upgrade it. This is a difficult feature to copy and make it work right because you need to perform database alterations by the right order. Some PHP database abstraction packages implement schema upgrading support in a limited fashion or do not impĺement it at all.
Other than that, it is a known fact that ADOdb author forged a benchmark to make it "show" that ADOdb is the fastest PHP database abstraction package and Metabase is the slowest. It seemed like Microsoft "Windows lowest TCO studies". They always make the studies conclude on their favour.
The truth is that the Metabase benchmark scripts were written by ADOdb author to use on purpose the slowest way to perform the benchmark tasks, as it is explained in this FAQ page:
meta-language.net/metabase-faq.html ...
I did not write Metabase to enter in any competition, so I never bother to protest.
Furthermore, those benchmarks do not evaluate the performance of execution database independent tasks.
If you are looking for a solution that provides the best performance, I suggest that you do not use any database abstraction packages at all. Just use the native PHP functions for each database directly and optimize the application to use database specific features.
Other than that, if you want to optimize the performance of database applications, portable or not, the best results can be achieved by avoiding to access the database as much as possible.
This may seem odd, but the truth is that database accesses are often the bottleneck of your applications. So the more you avoid accessing the database the faster the application may become.
Usually, you can maximize avoid accessing databases using (database) client side caches or using database job queues, as it is explained better here:
meta-language.net/metabase-faq.html ...
The basic conclusion is that if your database application is truly optimized, the database abstraction package that you use will hardly matter, as you did your best to avoid using it as much as possible.
Just so you have an idea, the PHPClasses site uses Metabase and content caching extensively. Last month it was using about 225,000 cache files that occupy over 1.3GB . The site performance is not affected by the database abstraction at all. Actually the greatest bottleneck, is the advertising that slows down the page loading, but that is a browser side issue.
Anyway, I wrote Metabase to be a reliable solution to develop truly database independent PHP applications. That is demonstrated by the 18 unit test tasks executed by the Metabase driver quality assurance script.
Nowadays, I use Metabase indirectly. I mean I use Metastorage to generate object-relational mapping classes. The generated classes are very compact and fast. They use Metabase to access the database and install the database schema parts.
meta-language.net/metastorage.html
Metastorage speeds up greatly the development of PHP Web applications. For now, Metastorage only generates code that works with Metabase.
In the future it may support PEAR::MDB2 . PEAR::MDB2 is the continuation of PEAR::MDB, which is a friendly fork of Metabase meant to have an API compliant with PEAR coding rules.
PEAR::MDB2 is now the database abstraction package officially recommended by the PEAR people. PEAR::DB is no longer recommended. It is in maintenance mode. This means that they will not develop it further. At most the will fix some bugs.
I have no time nor motivation to support ADOdb or any other database abstraction package to work with Metastorage generated code besides Metabase and PEAR::MDB2 .
Soon, there will be a new big repository for Metastorage based projects. I am not going to provide any more details until it is opened, but you can expect something big. It will provide great productivity enhancement to the development of PHP database applications.
Kaurov Eugene - 2006-06-05 14:40:44
Manuel Lemos - 2006-06-05 18:14:21 - In reply to message 1 from Kaurov Eugene
Shawn Koppenhoefer - 2014-12-30 12:33:26 - In reply to message 2 from Manuel Lemos
