在WordPress中使用其它数据库

WordPress正式版本目前只支持MySQL数据库引擎，很多用户都希望WordPress能够支持更多数据库，特别是开源程序PostgreSQL。本文综合了用户对这一话题的讨论，得出WordPress应该支持更多数据库的结论。

端口vs.整合

为你需要的数据库引擎创建一个端口，这是让数据库能在另一个已知程序上运行的最常见方法，这牵涉到对源代码的彻底检查。

为WordPress创建端口的问题在于，创建端口后，WordPress就不能随意地与原始代码库保持同步，与新功能和安全增强措施保持同样的更新速率了。

虽然端口能够满足人们的一些需要，但大多数用户都希望及时获取WordPress主程序中的最新安全措施和各种新功能，对他们来说端口并不是一种理想措施。这时将其他数据库整合到WordPress中是个值得考虑的解决方法，但开发人员也需要花费大量精力来编写查询语句，为数据库搭建抽象层。

数据库面临的问题

1. 目前的代码库非常倾向MySQL。WordPress用ezSQL来执行数据库调用，但调用抽象层时效果却不理想。ezSQL没有考虑到不同数据库中SQL语句执行的差异（引号是否包围文字，查询语句是否被限制，大小写敏感问题，等等），ezSQL提供的只是一个大体上的“查询”调用。这意味着大量的查询需要被改写——多么浩大的工程。

2. 数据库驱动型插件依靠现有执行，因此也使用倾向于MySQL的代码。即使需要改写wordpress代码以支持完整的数据库抽象层，数据库执行中的突发状况仍然可能破坏其他依靠数据库存取的插件。

3. 目前的标准数据库抽象层（ADOdb, Pear DB）不仅规模巨大而且结构复杂，他们的附属物可能跟WordPress规模相当甚至比wordpress更为庞大。这会削弱WordPress的兼容性以及安装的简便性。

解决方案

现状

WordPress核心开发人员保持着目前的开发方向，几乎没有将精力放在数据库的独立性上，因此的确有必要支持其它数据库。

支持方

• 这个方法已经被PostgreSQL采用，只需要日常维护已有代码
• 争取WordPress开发团队的合作不是难题
• 性能优化不涉及其他数据库

反对方

• 对端口开发人员来说，这个方法成本非常高。每当WordPress发布新版本，开发人员就要检查版本的非兼容情况，还要分别创建端口，测试等。
• 如果要使用其它数据库，用户支持率不高

使用PostgreSQL

尽可能地将必要抽象层放入ezSQL，使MySQL和PostgreSQL等效运行。

这样的话，安装时既能在ezSQL中加入Postgre抽象层，又能加入MySQL的抽象层，同时还能添加必要方法来分别这两者。改写SQL查询可兼容PostgreSQL/MySQL，也可以在ezSQL中用自定义插件来处理无法兼容的情况。届时用户可以在wp-config.php中选择所需要的数据库，而不用再考虑其它问题。

支持方

• 如果要同时支持PostgreSQL和MySQL数据库，这应该是花费精力最少也最节约成本的一种解决方案
• 只要安装了MySQL，依赖于MySQL的遗留插件仍然能正常运行
• 如果使用WordPress-Pg端口代码，这种方法会更加方便

反对方

• 这种解决方案限制了其他数据库的使用，总体上也没有使用某一个完整抽象层方便
• 某些查询不能用模糊的数据库语言（如，获取auto_increment/sequence的下一个值）来描述，这可能会导致抽象层和“直接存取”的混杂
• 处理抽象层错误时会很麻烦
• 一些开发人员可能不会将他们的开发动作同步更新到两个数据库中
• 数据库查询会分散到代码的每部分

WordPress特定数据库抽象层

WordPress特定数据库抽象层会将所有数据库查询（以及查询块）转换为函数调用，或者说转换为对象方法更为恰当，以获取数据库中的相关信息。

如果希望WordPress支持新数据库，可以通过为函数添加该数据库的代码来实现。获取某些信息块时，可以优化数据库并添加到相关函数中。

例如，如果数据库支持子查询，那么只要执行一次数据库查询就可以获取首页日志及日志评论总数，或者我们也可以用遗留MySQL来请求日志的数量。只要系统仍然使用MySQL，遗留插件就仍然有效。

支持方：

• 现在创建新数据库时再也不必在整个代码库中查找代码，只要在某一个文件中进行必要的代码和查询修改就可以了
• 优化、维护指定数据库时更加方便（例如使用子查询）;这可以抵消之前函数调用的系统开销。更新版本的MySQL也可以享受到这些优化的好处。
• 将来如果模式有变，要改动的文件也不会过多
• 用户不使用数据库范围外的数据库附属产品
• 改进模式时，也更容易让所有数据库受益
• 可支持RSS订阅、文本文件或安装其他博客软件（不仅仅是数据库）等无限存储后台。这同时还简化了代码的升级和迁移

反对方：

• 额外的函数调用和数据包会生成额外的系统开销
• 这种解决方案工作量较大，主要项目开发人员和插件开发人员都需要熟悉选定数据库抽象层的情况
• 如果开发人员不勤于更新，不同数据库的代码会出现不同步现象
• 在将来，可能要编写额外函数才可以访问数据库中的信息
• 为了达到最佳优化效果，需要预先研究哪些数据库能进行组访问

完整数据库抽象层

将WordPress中的所有查询转换为数据库抽象层（如ADOdb或Pear DB）函数。

支持方：

• 这种解决方案可以用最便捷的方式使用数据库，我们可以在WordPress上使用选定抽象层所支持的任何数据库

反对方：

• 这些工具能够生成大量附属产品，对依赖MySQL特别函数的遗留插件造成破坏
• 执行大规模数据库抽象层并不特别快，优化时也不能顾及多个数据库的利益
• 这种解决方案工作量很大（不过应该没有运行WordPress特定数据库抽象层的工作量大），要项目开发人员和插件开发人员都需要熟悉选定数据库抽象层的情况
• 开发人员需要经常性地更新数据库，保证数据库特定代码不介入查询，插件开发人员也是如此
• 在ADODb或者PEAR（很大程度上）中提取某些函数并不容易；WordPress使用这种函数时需要在程序端再次执行

开发成本

一些人会通过捐款来帮助开发其它WordPress数据库项目。

分类：中文手册