php - PDO vs pg_* 関数

Question

どちらも準備済みのステートメントを持っています。pg_* は libpq のラッパーです。右？

私は PHP の PDO が好きですが、今後データベースを変更するつもりはありません。どのライブラリを使用すればよいですか? ベンチマークはありますか？PHP バージョン: 5.4

Answer 1

PDO は優れたインターフェースを提供しますが、より汎用性が高くなるということは、各バックエンドの微妙な特異性に対処するのがより困難になるということでもあります。バグトラッカーを見ると、未解決の問題がいくつかあり、そのうちのいくつかは深刻です。

postgresql に関する事例証拠を次に示します。PDO のパーサーは、standard_conforming_strings を ON に設定すると問題が発生します (PG-9.1 の時点で、これがデフォルトになっています)。php-5.3.9 を使用したテスト ケース:

$dbh->exec("SET standard_conforming_strings=on");
$p=$dbh->prepare("SELECT 1 WHERE 'ab\' = :foo AND 'cd' = :bar");
$p->execute(array(":foo" => "ab", ":bar" => "cd"));

execute() は PDO 層で予期せず失敗し、 Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. :foo をパラメーターとして識別できないようです。

'ab\'=:foo別の条件なしで の後にクエリが停止した場合、クエリは正常に機能します。または、他の条件に文字列が含まれていない場合でも、正常に機能します。

この問題は問題 #55335に似ていますが、これはNot a bugとして却下されましたが、私の意見ではまったく間違っています。[実際、私は PDO を自分でハッキングして修正しましたが、他のバックエンドと互換性がないため、パッチはありません。クエリ字句解析器が非常に汎用的であることに戸惑いました。]

一方、pg_* は libpq に近いため、そもそもこの種の問題は発生しにくく、発生した場合でも解決しやすくなります。

したがって、私のポイントは、すべてが PDO に適しているわけではないということです。内部的には、これは確かに pg_* よりも困難であり、複雑さが増すということはバグが増えることを意味します。これらのバグは解決されていますか? 特定のバグトラッカー エントリに基づいていますが、必ずしもそうとは限りません。

Answer 2

具体的なDBに直接アプローチする関数（pg_、など）を使用するIMHOは、PDOまたはDBMSレイヤー（Doctrine oci_、mysql[i]_dibiなど）を使用するよりも常に少し高速です。

ただし、OOP アーキテクチャで PDO または任意の DBMS レイヤーを使用することは、より良いアプローチである必要があります (私見ですが)。もちろんアプリ内のDBエンジンを変更すればアプリ全体をわざわざ書き換える必要はありません。

DB エンジンを変更する予定がない場合でも、PDO の使用をお勧めします。しかし、それは私の意見です:-)

Answer 3

これはもっと好みの問題だと思います。 PDOコンパイルされているため高速である場合もあれば、ラッパーとして機能するためそうでない場合もあります。速度の違いは、あなたの決定に影響を与えないほど小さいと確信しています.

これは純粋な憶測ですが、PDO新しいものであり、現在 DB 接続の標準になっているようです。そのため、コードの観点からのサポートはおそらく増加しますが、サポートはmysql_*おそらくpg_*衰退し続けるでしょう。

の主な利点PDOは、その抽象化により、後で別の DB に切り替えることができることですが、そうではないに違いないため、決定が左右されることはないでしょう。

個人的には と一緒に仕事をする方が好きPDOです。「リソース」変数よりも、オブジェクトを渡して制御する方が簡単です。