PDO vs pg_ * functions

Question

They both prepared statements. pg_ * is a wrapper for libpq. Correctly?

I like PDO in PHP, but I will not change the database in the future. Which library should I use? Any benchmark? PHP Version: 5.4

Answer 1

PDO offers a nice interface, but greater versatility also means more problems to solve the subtle features of each backend. If you look at bugtracker , it has a number of open problems, and some of them are serious.

Here's anecdotal evidence with postgresql: the PDO parser has problems setting standard_conforming_strings to ON (which is now the default, as with 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 () function unexpectedly crashes at the PDO level with Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . It seems that it cannot determine: foo as a parameter.

If the request stops after 'ab\'=:foo , without another condition, it works fine. Or, if the other condition does not contain a string, it works fine.

The problem is similar to question No. 55335 , which was rejected as not a mistake, completely wrong, in my opinion. [In fact, I even hacked the PDO myself to fix it, but in a way that is incompatible with other backends, so no patch. I was confused by the fact that the lexical query analyzer was so general.]

On the other hand, pg_ * is closer to libpq, such a problem is likely to happen in the first place, and it is easier to solve if this happens.

So, I would say that not everything is good with PDO. Internally, this is of course more complex than pg_ *, and more complexity means more errors. Are these errors considered? Based on some error records, optional.

Answer 2

IMHO, using functions that are directly suitable for a specific database (for example, pg_ , oci_ , mysql[i]_ , etc.), is always a little faster than using PDO or any DBMS level (Doctrine, dibi, etc. .) ..

But the use of PDO or any DBMS level in the OOP architecture should be the best approach (IMHO, again), since you will learn to use this level and, therefore, will use it for any DB mechanism. Of course, if you change the DB mechanism in the application, you do not have to worry about rewriting the entire application.

Even if you do not plan to change the database engine, I would recommend using PDO. But this is just my opinion :-)

Answer 3

I think it is rather a matter of taste. PDO may be faster because it is compiled, or it may not be as it acts like a wrapper. I am sure that the difference in speed will be small enough not to affect your decision.

This is pure speculation, but PDO is new and seems to be the standard for database connections now, so its support from the code point of view is likely to grow, while support for mysql_* and probably pg_* will continue to weaken.

The main advantage of PDO is that its abstraction will allow you to switch to another database later, but I’m sure you won’t do this, so it probably shouldn’t affect your decision either.

I personally prefer to work with PDO . It is easier to transfer and manage objects than "resource" variables.