PDO vs pg_ * Funktionen

Question

Sie haben beide vorbereitete Aussagen. pg_ * ist ein Wrapper für libpq. Recht?

Ich mag das PDO in PHP, aber ich werde die Datenbank in der Zukunft nicht ändern. Welche Bibliothek sollte ich verwenden? Jeder Benchmark? PHP-Version: 5.4

Answer 1

IMHO mit den Funktionen, die direkt Beton DB nähert sich (wie pg_, oci_, mysql[i]_ etc.) ist immer ein bisschen schneller dann eine gU oder jede DBMS-Schicht unter Verwendung von (Lehre, dibi, etc.) .

Aber mit PDO oder jeder DBMS-Schicht in OOP-Architektur sollte besser Ansatz sein (IMHO, wieder), wie Sie lernen, diese Schicht zu verwenden und damit wird es auf was auch immer DB-Engine ist dahinter. Natürlich, wenn Sie die DB-Engine in der App ändern, müssen Sie sich nicht mit dem Umschreiben der ganzen App kümmern.

Auch wenn Sie nicht planen, die DB-Engine zu ändern, würde ich die Verwendung von PDO empfehlen. Aber das ist nur meine Meinung :-)

Answer 2

Ich denke, dass dies mehr eine Frage des Geschmacks ist. PDO kann schneller sein, da es kompiliert wurde, oder es kann nicht sein, da es als Wrapper fungiert. Ich bin sicher, dass der Geschwindigkeitsunterschied klein genug ist, um Ihre Entscheidung nicht zu beeinflussen.

Das ist reine Spekulation, aber PDO ist neu und scheint nun der Standard für die DB-Verbindungen zu sein, so dass die Unterstützung für sie in Bezug auf den Code wird wahrscheinlich wachsen, während die Unterstützung für mysql_* und wahrscheinlich pg_* wird schwinden weiter. Der große Vorteil von PDO ist, dass seine Abstraktion es Ihnen später erlauben wird, zu einer anderen Datenbank zu wechseln, aber ich wette, dass Sie das nicht tun werden, so dass das Ihre Entscheidung wahrscheinlich auch nicht beeinflussen sollte.

Ich persönlich bevorzuge mit PDO arbeiten. Es ist einfacher, Objekte als "Ressourcen" -Variablen zu übergeben und zu steuern.

Answer 3

PDO bietet eine schöne Schnittstelle, aber mehr Generizität bedeutet auch mehr Ärger, um mit subtilen Eigenheiten jedes Backends umzugehen. Wenn Sie the bugtracker betrachten, hat es eine Reihe von offenen Problemen, und einige von ihnen sind ernst.

Hier ist eine anekdotische Beweise mit Postgresql: PDO Parser hat Probleme mit Standard_conforming_strings auf ON (das ist jetzt der Standard, wie von PG-9.1). Testfall mit 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")); 

Die execute() nicht unerwartet bei der PDO-Schicht mit Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. Es scheint, dass es nicht möglich ist: foo als Parameter zu identifizieren.

Wenn die Abfrage nach 'ab\'=:foo ohne eine andere Bedingung stoppt, dann funktioniert es gut. Oder wenn die andere Bedingung keine Zeichenfolge enthält, funktioniert es auch.

Das Problem sieht issue #55335 ähnlich, dass als einen Bug, ganz zu Unrecht meiner Meinung nach nicht entlassen wurde. [Eigentlich habe ich sogar selbst PDO gehackt, um es zu reparieren, aber auf eine Weise, die mit anderen Backends inkompatibel ist, also kein Patch. Ich war beunruhigt, dass der lexikalische Abfrage-Analyzer so generisch war.] Andererseits, pg_ * ist näher an libpq, diese Art von Problem ist weniger wahrscheinlich, in erster Linie zu passieren, und einfacher zu lösen, wenn es tut, auf der anderen Seite, pg_ *.

Also mein Punkt wäre, dass nicht alles mit PDO nett ist. Intern ist es sicherlich eine größere Herausforderung als pg_ * und mehr Komplexität bedeutet mehr Bugs. Werden diese Fehler behoben? Basierend auf bestimmten Bugtracker-Einträgen, nicht unbedingt.