PDO может быть быстрее, так как он скомпилирован, или нет, так как он действует как обертка. Я уверен, что разница в скорости будет достаточно мала, чтобы не повлиять на ваше решение.

Это чистое предположение, ноPDO является новым и, кажется, сейчас является стандартом для соединений с БД, поэтому поддержка его с точки зрения кода, вероятно, будет расти, тогда как поддержкаmysql_* и, вероятно,pg_* продолжит уменьшаться.

Главное преимуществоPDO в том, что его абстракция позволит вам позже переключиться на другую БД, но я уверен, что вы этого не сделаете, так что, вероятно, это не должно повлиять на ваше решение.

Я лично предпочитаю работать сPDO. Проще передавать и контролировать объекты, чем переменные "ресурса".

но большая универсальность также означает больше проблем при работе с тонкими особенностями каждого бэкэнда. Если вы посмотрите на багтрекер, у него есть ряд открытых вопросов, и некоторые из них серьезные.

Вот анекдотическое свидетельство с 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"));

Execute () неожиданно завершается с ошибкой на уровне PDO сDatabase error: SQLSTATE[HY093]: Invalid parameter number: :foo. Кажется, он не может определить: foo как параметр.

Если запрос останавливается после'ab\'=:foo, без каких-либо условий, значит работает нормально. Или, если другое условие не содержит строку, оно тоже работает нормально.

Проблема похожа наissue # 55335, это было отклонено как Не ошибка, на мой взгляд, совершенно неправильно. [На самом деле, я даже сам взломал PDO, чтобы это исправить, но таким образом, что это несовместимо с другими бэкэндами, так что патча нет. Я был смущен тем, что лексический анализатор запросов настолько универсален.]

С другой стороны, если pg_ * ближе к libpq, проблема такого рода менее вероятна, и ее легче решить, если это произойдет.

Так что я хочу сказать, что не все в порядке с PDO. Внутренне это, конечно, более сложно, чем pg_ *, а большая сложность означает больше ошибок. Устранены ли эти ошибки? Основано на некоторых записях ошибок, не обязательно.

которые подходят непосредственно к конкретной БД (например,pg_, oci_, mysql[i]_ и т. д.) всегда немного быстрее, чем использование PDO или любого уровня СУБД (Doctrine, dibi и т. д.).

Но использование PDO или любого уровня СУБД в ООП-архитектуре должно быть более подходящим (ИМХО, опять же), так как вы научитесь использовать этот уровень и, таким образом, будете использовать его на любом механизме БД. Конечно, если вы меняете движок БД в приложении, вам не нужно беспокоиться о переписывании всего приложения.

Даже если вы не планируете менять движок БД, я бы порекомендовал использовать PDO. Но это только мое мнение :-