代替データベースの使い方

現在のところ、公式な WordPress のディストリビューションは MySQL データベースエンジンのみに対応しています。多くの方が他のデータベースエンジン（特にオープンソース PostgreSQL）対応への要望を求めてきました。このページは同トピックに関して以前に英語版フォーラムで行われた議論のまとめであり、WordPress による他のデータベースの対応へのしっかりしたロードマップを確立するために書かれました。

既存のプロジェクトにて他のデータベースエンジンへの対応を追加するために最も一般的なのは、ソースコードを完全に書き直し、あるエンジンへの参照部分を別のものと入れ替えるという方法です。つまり、選択したデータベースエンジンに対応する移植版を作成するということです。

WordPress 移植版作成の欠点は、元のコードベースと同期させ、機能やセキュリティ改善等を最新に保つのが難しいという点です。これは、キーナン・ティムズの WordPress 1.2 向け PostgreSQL 移植版を見ても明らかです。このプロジェクトは現在セキュリティに問題があり、古くなってしまっています。さらに最近ではアーウィン ・ウォルフによる 移植版も Source Forge にあります。

これは素晴らしい最初の一歩であり一部のニーズに答えるには十分かもしれませんが、移植という方法は最新のセキュリティ対策や機能を手に入れたい多くのユーザーにとって理想的ではありません。より良い解決策は、代替データベース対応を WordPress に統合するという方法でしょう。しかし、こちらの方法は移植しやすいクエリを書ために開発者が協調努力し、適切な抽象レイヤをまとめる必要があります。

1. 現在のコードベースは非常に MySQL を中心としたものとなっている。WordPress はデータベースコールを実装するために ezSQL クラスを使ってはいるが、これは抽象化レイヤと呼ぶには適切ではない。異なるデータベースにおける異なる SQL 構文の実装（リテラルの引用符囲い、クエリ構文の制限、大文字小文字の区別、など）には ezSQL では対応しておらず、一般的なクエリコールが提供されているだけである。つまり、多大な数のクエリを再度書かなければならず、非常に大規模な作業となってしまう。
2. データベースを使って動くプラグインは現在の実装に依存しており、MySQL 向けのコードになっている。もしデータベース抽象化レイヤへの完全対応に向けて WordPress のコードをすべて書き換える場合、データベース実装の急激なシフトが起こった際にはデータベースアクセスに依存するプラグインなどが使えなくなる可能性が高い。
3. 現在の標準データベース抽象化レイヤ（ADOdb、Pear DB）は非常に規模が大きく複雑であり、WordPress と同様もしくはそれ以上の依存性に相当することになってしまう。これは、WordPress のポータビリティやインストールの簡単さに影響を与える可能性がある。

現在の開発版の方向性を続ける。データベース独立性については WordPress コア開発者はほとんど重きをおいておらず、他のデータベースに対応するにはフォーク（分岐）が必要だと言えます。

良い点:

• （少なくとも）PostgreSQL 対応向けとしてはこのアプローチはすでに環境が整っており、既存のコードを管理するだけでよい。
• WordPress 開発チームからの協力は必要ではない。
• 他のデータベースを無視してパフォーマンス最適化を行える。

悪い点:

• 移植を行う開発者にとって非常に負担が重い。WordPress がリリースされる度に互換性をチェックし、移植を行い、独立したテストを行う必要がある。
• 代替データベース利用者には WordPress チームからのユーザーサポートが期待できない。

ezSQL を拡張し、MySQL と PostgreSQL が同様にうまく作動するために必要な抽象化レイヤを含める方法です。

これは ezSQL の Postgres や MySQL 抽象化を設定に含め、これら2つの間を汎用化する必要なメソッドを追加するというだけのことです（例: limitQuery メソッドなど）。全体の SQL クエリを書き直し、PostgreSQL/MySQL 互換にし、ezSQL の独自拡張を使って互換性のないところを処理します。ユーザーは wp-config.php 内でどちらのデータベースを使用するか設定し、それ以降何も考える必要はありません。

良い点:

• これは PostgreSQL と MySQL 両方に適切に対応するための、影響が少なく大規模な依存をしない最低限の解決法だと考えられる。
• MySQL に依存しているレガシープラグインも、MySQL インストール上ならそのまま機能する。
• 既存の WordPress-Pg 移植を使うことで、このアプローチがさらに簡単になることもありうる。

悪い点:

• この解決法では簡単に他のデータベースへ対応できない。また、何らかの完全な抽象化レイヤを使うのに比べるとかなりクリーンさが減少する。
• 一部のクエリはデータベースを認識しない方法ではどうしても表現できない（例: auto_increment/sequence の次の値を取得する）ため、抽象化と直接的なアクセスが醜く混合した状態を引き起こす可能性がある。
• エラー対応の抽象化が難しい（？）
• 変更を療法のデータベース向けに同期しない開発者（コアプロジェクトとプラグイン両方）がいるかもしれない。
• データベースクエリはコードのあちこちに散らばったままになる。

データベースから関連する情報を取ってくるための WordPress 内のすべてのクエリ（およびクエリブロック）をサブルーチンに変換します。もしくはさらに適切な手段としてオブジェクトメソッドを使うという方法です。

これらの関数にコードを追加することによって、新しく別のデータベースへ対応することができます。ある情報ブロックを取得する際、特定のデータベースに対する最適化を関連する関数に追加することもできます。

例えばフロントページの投稿とそのコメント数を取得する場合、サブクエリに対応しているデータベースばらクエリ1つで完了しますが、レガシー MySQL では最低でも表示する投稿数プラス1つのクエリが必要です。MySQL を使っている場合も、レガシープラグインが動作できるようにするべきです。

良い点:

• 新しいデータベースに対応するために修正が必要なコードとクエリがすべて1つのファイルに収まる。現在のようにむやみにあちこちのコードベースに散らばることがない。
• 特定のデータベース向けの最適化の実装と管理が比較的容易（例: subselect の使用）。これにより関数呼び出しのオーバーヘッドをオフセットできる可能性がある。
• 将来的なスキーマ変更やクリーンアップに必要なファイルを減らせる。
• ユーザーが使用しているデータベースに対応する以外の新しい依存状況を作り出さない。
• すべてのデータベースに役に立つスキーマ改善の実装が簡単になる。
• RSS フィード、テキストファイルなど任意のストレージバックエンドや、（データベースだけではなく）他のブログソフトウェアにも対応できる。これにより、アップグレードや移行がさらにクリーンで簡単になる。

悪い点:

• 追加の関数呼び出しおよびデータのパッケージングによりオーバーヘッドが少し追加される。
• この選択肢にはかなりの作業量が必要となり、コアプロジェクト及びプラグイン作者もこの仕組みに詳しくならなくてはいけない。
• 様々なデータベース向けのコードの同期を保つには開発者の努力が必要。
• 将来的にデータベースのデータに新しい手段でアクセスするため、関数の追加が必要になる。
• 可能な限りの最適化を行うには、データベースアクセスのグループ化をどうするか事前によく考える必要がある。

WordPress 内のすべてのクエリを、ADOdb や Pear DB などのデータベース抽象化レイヤを使った関数に変換する方法です。

良い点:

• できる限りポータブルな方法のデータベース利用をクリーンに実装できる。選択したデータベース抽象化レイヤに対応しているどんなデータベースでも WordPress を使えるようになる。

悪い点:

• これらのツールに大きく依存する状態になり、MySQL 特定の関数に依存したレガシープラグインが動かなくなる。
• 大規模かつ一般的なデータベース（および永続オブジェクト）の抽象化実装は非常に高速にはなりづらい。また、特定のデータベースのためになる最適化を利用できない場合がある。
• この選択肢は非常に作業が多くなり（ただし WordPress 向けレイヤーの実装よりは少ない可能性が高い）、メインプロジェクトやプラグインの開発者は選択した抽象化レイヤに精通している必要がある。
• コア＆プラグイン開発者は、抽象化レイヤを無視したデータベース特定のコードがクエリに含まれないように非常に気を配る必要がある。
• 一部の機能は ADODb や（特に）PEAR では抽象化できない。もし WordPress が公いった機能を利用している場合アプリケーション側で再実装する必要があるかもしれず、パフォーマンスに影響を与える。

多くの人が（過去のフォーラム議論を参照）上記のような WordPress 代替データベース選択肢のいずれかへの開発コストに対して寄付をする提案をしている。

最新英語版： WordPress Codex » Using_Alternative_Databases （最新版との差分）