PDO対pg_ *機能

Question

これらはどちらも準備済みの文を持っています。 pg_ *はlibpqへのラッパーです。右？

私はPHPでPDOが好きですが、将来はデータベースを変更するつもりはありません。 どのライブラリを使用しますか？ ベンチマークはありますか？ PHPバージョン：5.4

Answer 1

私見直接コンクリートDB（等pg_、oci_、mysql[i]_など）を少し速くPDOまたは任意のDBMS層（等教義、DIBI）を用い、その後常にに近づく関数を使用して。

しかし、PDOやOOPアーキテクチャの任意のDBMSレイヤーを使用すると、このレイヤーを使用する方法を学ぶので、より良いアプローチ（IMHO、もう一度）が必要になります。もちろん、アプリ内でDBエンジンを変更した場合、アプリ全体の書き換えを気にする必要はありません。

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

Answer 2

これはもっと味の問題だと思います。 PDOは、コンパイルされているので高速であるかもしれませんし、ラッパーとして機能するのでそうでないかもしれません。私はあなたの決定に影響を与えないように速度差が十分に小さいと確信しています。

これは純粋な憶測ですが、PDOは、新規であり、現在のDB接続の標準のようですので、コードの面で、それに対するサポートは、おそらく成長する、mysql_*の支援に対し、おそらくpg_*が衰退していきます。

PDOの主な利点は、その抽象化によって後で別のDBに切り替えることができるということですが、私はそうではないと考えています。

私は個人的にPDOで作業することを好みます。 「リソース」変数よりもオブジェクトを渡して制御する方が簡単です。

Answer 3

PDOはすばらしいインターフェイスを提供しますが、より一般性が高いため、各バックエンドの微妙な特異性に対処するのが難しくなります。 the bugtrackerを見ると、未解決の問題が多数あり、そのうちのいくつかは深刻です。

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")); 

（実行）が予期せず Database error: SQLSTATE[HY093]: Invalid parameter number: :foo有するPDO層で失敗します。これはパラメータとしてfooを識別することができないようです。

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

issue #55335と似ていますが、として却下されました。、私の意見では間違っています。 [実際に、私はそれを修正するために自分でPDOをハッキングしましたが、他のバックエンドと互換性のない方法で、パッチはありません。私はクエリの語彙アナライザが非常に一般的であることに戸惑いました。]

一方、pg_ *はlibpqに近いため、この種の問題は最初は起こりにくく、そうであれば解決しやすくなります。

私の主張は、PDOではすべてがうまくいかないということです。内部的には、pg_ *よりも確かに挑戦的ですが、複雑さが増えるほどバグが多くなります。これらのバグは対処されていますか？特定のbugtrackerエントリに基づいていますが、必ずしもそうではありません。