问题
They both have prepared statements. pg_* is a wrapper to libpq. Right?
I like the PDO in PHP, but I'm not going to change the database in the future. Which library should I use? Any benchmark? PHP version: 5.4
回答1:
PDO offers a nice interface but more genericity also means more trouble to deal with subtle idiosyncrasies of each backend. If you look at the bugtracker, it has a number of open issues, and some of them are serious.
Here's an anecdotal evidence with postgresql: PDO's parser has trouble with standard_conforming_strings set to ON (which is now the default, as of PG-9.1). Test case with 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"));
The execute() unexpectedly fails at the PDO layer with
Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. It seems that it's unable to identify :foo as a parameter.
If the query stops after 'ab\'=:foo, without another condition, then it works fine.
Or if the other condition does not include a string, it works fine too.
The problem looks similar to issue #55335 , that was dismissed as Not a bug, quite wrongly in my opinion. [Actually, I've even hacked PDO myself to fix it, but in a way that is incompatible with other backends, so no patch. I was disconcerted by the query lexical analyzer being so generic.]
On the other hand, pg_* being closer to libpq, this kind of problem is less likely to happen in the first place, and easier to solve if it does.
So my point would be that not everything is nice with PDO. Internally, it's certainly more challenging than pg_*, and more complexity means more bugs. Are these bugs addressed? Based on certain bugtracker entries, not necessarily.
回答2:
IMHO using the functions that approaches directly concrete DB (like pg_, oci_, mysql[i]_ etc.) is always a little bit quicker then using a PDO or any DBMS layer (Doctrine, dibi, etc.).
But using PDO or any DBMS layer in OOP architecture should be better approach (IMHO, again), as You learn to use this layer and thus will use it on whatever DB engine is behind. Of course if You change the DB engine within the app You do not have to bother with rewriting of whole the app.
Even if You are not planning to change the DB engine I would recommend using of PDO. But thats just my opinion :-)
回答3:
I think that this is more a matter of taste. PDO may be faster since it's compiled, or it may not be since it acts as a wrapper. I am sure that the speed difference would be small enough not to impact on your decision.
This is pure speculation, but PDO is new and seems to be the standard for DB connections now, so support for it in terms of the code will probably grow, whereas support for mysql_* and probably pg_* will continue to wane.
The major advantage of PDO is that its abstraction will allow you to switch to a different DB later, but I bet you won't, so that probably shouldn't sway your decision either.
I personally prefer to work with PDO. It's easier to pass and control objects than "resource" variables.
来源：https://stackoverflow.com/questions/10384224/pdo-vs-pg-functions