PDO与pg_*函数

Question

他们都准备好了陈述.pg_*是libpq的包装器.对？

我喜欢PHP中的PDO,但我将来不会更改数据库.我应该使用哪个库？任何基准？PHP版本:5.4

Answer 1

PDO提供了一个很好的界面,但更通用性也意味着更难以处理每个后端的细微特性.如果你看一下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"));

执行()意外地在PDO层失败 Database error: SQLSTATE[HY093]: Invalid parameter number: :foo.似乎它无法识别:foo作为参数.

如果查询在'ab\'=:foo没有其他条件的情况下停止,那么它可以正常工作.或者如果其他条件不包含字符串,它也可以正常工作.

问题看起来类似于问题#55335,被认为是非错误,在我看来是非常错误的.[实际上,我甚至自己修复了PDO来修复它,但是在某种程度上与其他后端不兼容,所以没有补丁.我对查询词法分析器如此通用感到不安.]

另一方面,pg_*更接近libpq,这种问题首先不太可能发生,如果有的话更容易解决.

所以我的观点是PDO并不是一切都很好.在内部,它肯定比pg_*更具挑战性,更复杂意味着更多的错误.这些错误是否得到解决？基于某些bugtracker条目,不一定.

Answer 2

恕我直言，使用直接接近具体数据库的函数（如、pg_等）总是比使用 PDO 或任何 DBMS 层（Doctrine、dibi 等）快一点。oci_mysql[i]_

但是在 OOP 架构中使用 PDO 或任何 DBMS 层应该是更好的方法（恕我直言，再次），因为您学习使用该层，因此将在后面的任何数据库引擎上使用它。当然，如果您更改应用程序内的数据库引擎，您不必费心重写整个应用程序。

即使您不打算更改数据库引擎，我也会建议使用 PDO。但那只是我的个人意见 ：-）