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。
