Write once - run anywhere
一次编写——随处运行
这是Java的一句行销口号，但是它同时也是PHP的关键特性之一。许多商业模型依赖于操作系统无关性来保证产品能够销售给广泛的客户群体。因而，为什么要把你自己绑在某种数据库厂商的身上呢？数据库抽象层使得你能够与数据库独立的开发你的应用程序。但是，通常情况下它们对性能的影响超过了你所希望的，要么他们并不足够抽象以消除所有和特定数据库相关的代码。
这篇文章将教给我什么？
这篇文章将对数据库抽象包 PEAR MDB 有一个很好的介绍。文章的焦点将是对 MDB 超越类似包所提供的更先进的特性，例如数据类型抽象和基于 XML 的 schema 管理。对 PHP 和 SQL 的基本理解是推荐的。
为什么另外再要一个数据库类？
通常， web 工程在客户已经确定了要使用那种 RDBMS （关系型数据库管理系统）之后被添加给已经存在的 IT 基础结构。即使那并不是因为不同的预算可能影响的你选择何种数据用于部署的情况。最终，你作为开发者可能简单的偏好于不把自己绑在某个厂商身上。自此，意味着给每个支持的数据保持版本或者牺牲更多性能但是获得多于必须的易用性：走入 PEAR MDB 吧。
MDB 是着眼于使得编写 RDBMS 无关的 PHP 程序成为简单的过程的数据库抽象层。大部分其他的 PHP 的所谓数据库抽象层紧紧给所有支持的数据库提供了一个公用 API 以及非常有限的抽象（大部分只是针对序列的）。MDB 另一方面能够用来抽象所有数据库发送和接收的数据。甚至数据库 schema 都能被定义为 RDBMS 无关的格式。但是它提供这些功能的同时仍然保持了很高的性能以及简单易用。这是通过深入观察两个流行的数据库抽象层，PEAR DB 和 Metabase， 之后并且对它们进行了融合后获得的。而且在融合过程中，趁着这个机会清理了它们融合后的 API 以及任何影响性能的设计。
MDB 是怎样出现的？
早在 2001 年的秋天，我就在寻找一种可能能够让我公司的程序框架与 RDBMS 独立的数据库抽象包。这个目标是把特定数据库相关的代码数量减少到零。我发现提供这样的功能的唯一的一个包是 Metabase。但是 Metabase有一些部分是因为为了和 PHP3 兼容的让人不舒服的 API。尽管如此，我们决定 Metabase 是我们唯一的选择。但是即使是在给 Metabase 增加了一个性能改进的补丁之后，我们仍然感到我们放弃了太多的性能。我们在 2001 年的 PHP 国际会议上碰到了 Metabase 的作者，并且我们谈论了让像 Metabase 这样的东西成为 PEAR 工程一部分的好处。后来不久，在 PEAR 邮件列表上就 PEAR DB 和 Metabase 融合的可能的好处又开始了一场讨论。在我们公司进行了许多讨论之后，我们决定承担这个任务。数个月的艰辛工作之后，我们现在有了 MDB 的第一个稳定的 release。
