Оба они подготовили заявления. pg_ * – это оболочка для libpq. Правильно?
Мне нравится PDO в PHP, но я не буду менять базу данных в будущем. Какую библиотеку я должен использовать? Любой бенчмарк? Версия PHP: 5.4
PDO предлагает приятный интерфейс, но большая универсальность также означает больше проблем для решения тонких особенностей каждого бэкэнда. Если вы посмотрите на bugtracker , у него есть ряд открытых проблем, и некоторые из них серьезны.
Вот эпизодическое доказательство с postgresql: у парсера PDO возникают проблемы с установкой стандартного_конформирования_строка в значение 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 с Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Кажется, что он не может идентифицировать: foo как параметр.
Если запрос останавливается после 'ab\'=:foo , без другого условия, то он отлично работает. Или, если другое условие не содержит строку, оно отлично работает.
Проблема похожа на вопрос № 55335 , который был отклонен как « Не ошибка» , совершенно ошибочно, на мой взгляд. [На самом деле, я даже взломал PDO самостоятельно, чтобы исправить это, но таким образом, что это несовместимо с другими бэкэндами, поэтому никакого патча. Я был смущен тем, что лексический анализатор запросов был таким общим.]
С другой стороны, pg_ * находится ближе к libpq, такая проблема, скорее всего, произойдет в первую очередь, и проще решить, если это произойдет.
Поэтому я бы сказал, что не все хорошо с PDO. Внутренне это, конечно, более сложно, чем pg_ *, и больше сложностей означает больше ошибок. Рассматриваются ли эти ошибки? Основываясь на некоторых записях ошибок, необязательно.
ИМХО, используя функции, которые подходят непосредственно к конкретной БД (например, pg_ , oci_ , mysql[i]_ и т. Д.), Всегда немного быстрее, чем использование PDO или любого уровня СУБД (Doctrine, dibi и т. Д.).
Но использование PDO или любого уровня СУБД в архитектуре ООП должно быть лучшим подходом (ИМХО, опять же), поскольку вы научитесь использовать этот уровень и, следовательно, будете использовать его для любого механизма БД. Конечно, если вы измените механизм БД в приложении, вам не нужно беспокоиться о переписывании всего приложения.
Даже если вы не планируете менять механизм БД, я бы рекомендовал использовать PDO. Но это только мое мнение 🙂
Я думаю, что это скорее вопрос вкуса. PDO может быть быстрее, поскольку он скомпилирован, или может быть не так, поскольку он действует как обертка. Я уверен, что разница в скорости будет достаточно мала, чтобы не повлиять на ваше решение.
Это чистая спекуляция, но PDO является новой и, похоже, сейчас является стандартом для соединений с БД, поэтому поддержка для нее с точки зрения кода, вероятно, будет расти, тогда как поддержка mysql_* и, вероятно, pg_* будет продолжать ослабевать.
Основным преимуществом PDO является то, что его абстракция позволит вам перейти на другую БД позже, но я готов поспорить, что вы этого не сделаете, так что, вероятно, также не должно повлиять на ваше решение.
Я лично предпочитаю работать с PDO . Легче передавать и управлять объектами, чем переменные «ресурс».