Write once - run anywhere
Write once - run anywhere
This is a marketing slogan for Java, but it is also one of the key features of PHP. Many business models rely on operating system independence to ensure that products can be sold to a broad customer base. So why tie yourself to a certain database vendor? The database abstraction layer enables you to develop your applications independently of the database. However, often they impact performance more than you would like, or they are not abstract enough to eliminate all database-specific code.
What will this article teach me?
This article will give a good introduction to the database abstraction package PEAR MDB. The focus of the article will be on more advanced features of MDBs beyond those offered by similar packages, such as data type abstraction and XML-based schema management. Basic understanding of PHP and SQL recommended.
Why do we need another database class?
Typically, web projects are added to an existing IT infrastructure after the customer has determined which RDBMS (relational database management system) they want to use. Even that's not the case because different budgets may affect what data you choose to deploy. Ultimately, you as a developer may simply prefer not to tie yourself to any one vendor. From now on, it means keeping versions of each supported data or sacrificing more performance but gaining more usability than necessary: Enter PEAR MDB.
MDB is a database abstraction layer focused on making writing RDBMS-agnostic PHP programs a simple process. Most other so-called database abstraction layers for PHP provide a common API for all supported databases and very limited abstractions (mostly just for sequences). MDB on the other hand can be used to abstract all data sent and received by the database. Even the database schema can be defined in an RDBMS-independent format. But it provides these features while still maintaining high performance and simplicity of use. This was achieved by taking a deep look at two popular database abstraction layers, PEAR DB and Metabase, and then merging them. And during the integration process, we took this opportunity to clean up their integrated APIs and any designs that affected performance.
How did MDB appear?
Back in the fall of 2001, I was looking for a database abstraction package that might make my company's programming framework RDBMS independent. The goal is to reduce the amount of database-specific code to zero. The only package I've found that provides such functionality is Metabase. But some parts of Metabase have an uncomfortable API for compatibility with PHP3. Nonetheless, we decided that Metabase was our only option. But even after adding a performance improvement patch to Metabase, we still felt we were giving up too much performance. We met the authors of Metabase at the PHP International Conference in 2001, and we talked about the benefits of having something like Metabase be part of the PEAR project. Shortly afterwards, another discussion started on the PEAR mailing list about the possible benefits of converging PEAR DB and Metabase. After many discussions in our company, we decided to take on this task. After months of hard work, we now have the first stable release of MDB.