php 主要是由志愿者完成的项目；尽管有少数一些固定的“核心”开发人员，但是我们没有一个人在全职受薪的开发 php。除此之外，我们分别位于世界不同地方，您可以想象长期开发的协调工作是何等困难。因此，php 主要是基于突发奇想的个人短期需求来发展的，北京写字楼其原因也多种多样，有的是试验，有的则是因为“明天有活要交”。尽管这样通常每一步都会改善 php，但从长远来看则是缺乏完整性 － 数据库扩展就是一个重要的例子hkrfp。
在各种不同的数据扩展（oci、mysql、postgresql、mssql 等）之间根本没有真正的一致性，甚至在某些情况下，在这些扩展内部也没有真正的一致性。几乎所有这些扩展都在使用与基础数据库 api 紧密相连的不同代码完成着相同种类的任务。而且因为我们（php 核心开发人员和扩展开发人员）的人手非常有限，因此这就造成了代码更加难以维护，从而为 php 带来了很大的问题。
由于 php 越来越受欢迎并不断成功，因此主要 php 数据库扩展的维护者们参加了在德国举行的 linuxtag 2003 大会，在会上我们交换了对 php 前景的看法。在讨论 php 发展的随机性时，我们确定了在 php 中进行数据库访问的一些目标：
?提供一种轻型、清晰、方便的 api
?统一各种不同 rdbms 库的共有特性，但不排除更高级的特性。
?通过 php 脚本提供可选的较大程度的抽象/兼容性。
我们之所以提出了这种 php 数据对象 (pdo) 的概念，是因为我们希望通过采用 zend engine 2（php 5 的核心）先进的面向对象特性获得该 api 的一些更优秀的性能北京保洁。
php 中的数据抽象层概念一点都算不上新；在 google 中查询“php database abstraction”会找到大约 83,200 个匹配项。它几乎是许多 php 开发人员梦寐以求的，而其产生则部分归因于我们不完整的 api。如果您曾经尝试过使用第三方抽象层来完成任何真正重要的工作，通常会发现这些抽象层对于手头的工作来说设计的功能过于强大了 －或者表现为在使用前需要进行大量学习，或者表现为接口速度缓慢，参数需要经过多层脚本函数调用才能到达数据库自有的 api；通常是存在上述两种表象。
为什么这些抽象层会存在这种问题？这些抽象层总是在试图完成太多的任务，甚至可能是不可能的任务。我们决定以实用为目标，仅将一些最常见的数据库 api 特性作为我们的基础，并使得 pdo 驱动程序能够将它们特定于产品的特性暴露为常规扩展函数。
为什么使用 pdo？
听过有关数据库抽象扩展谣传的大多数人会立刻对 pdo 的扩展方面产生疑惑 － 我们是否要分析 sql，将其转换为相应的后端方言呢？我们如何处理特性 x 或特性 y，等等。因此，当您听说我们在 pdo 中根本不用为此而担忧时可能会大吃一惊；我们夏令营不希望使所有内容都完全统一，因为要使得这种统一成为可能，只能是将自己限制在最低的通用标准。
如果 pdo 不是一个整体的抽象层，那还有什么别的原因值得您考虑使用它吗？
?性能。pdo 从一开始就吸取了现有数据库扩展成功和失败的经验教训。因为 pdo 的代码是全新的，所以我们有机会重新开始设计性能，以利用 php 5 的最新特性。
?能力。pdo 旨在将常见的数据库功能作为基础提供，同时提供对于 rdbms 独特功能的方便访问。
?简单。pdo 旨在使您能够轻松使用数据库。api 不会强行介入您的代码，同时会清楚地表明每个函数调用的过程。
?运行时可扩展。pdo 扩展是模块化的，使您能够在运行时为您的数据库后端加载驱动程序，而不必重新编译或重新安装整个 php 程序。例如，pdo_oci 扩展会替代 pdo 扩展实现 oracle 数据库 api。还有一些用于 mysql、postgresql、odbc 和 firebird 的驱动程序，更多的驱动程序尚在开发。
您可能想了解 pdo 与其他常用的抽象层的对比情况，例如 pear db 或 adodb。无论在 api 方面还是在性能方面，pdo 都比其他常见抽象层要轻型，但是涉及到在各个数据库后端之间提供统一性方面，则不如那些抽象层，例如用于处理大量可移植性问题的 pear mdb 2 抽象层。
在哪里可以获得 pdo？
pdo 是通过 pecl（发音为“pee-kle”，欧洲语言风格），即 php 扩展库提供的。如果您在运行 linux 计算机，请按照下面的说明进行设置；稍后是在 windows 上安装的详细信息。
请注意，pdo 及其驱动程序当前处于“alpha”状态；这就意味着我们会合理保证没有重大缺陷，但是该程序包功能并不完善 － 我们还要添加很多功能。虽然我们鼓励您测试该程序包，但是实在不推荐在现阶段将其用于生产。