Ну, вы могли бы поспорить с объектно-ориентированным аспектом, подготовленными утверждениями, фактом, что он становится стандартом, и т. Д. Но я знаю, что большую часть времени, когда кто-то убеждает, лучше работает с функцией убийцы. Итак, вот оно:

Отличная вещь с PDO - вы можете получать данные, автоматически вставляя их в объект. Если вы не хотите использовать ORM (потому что это всего лишь быстрый скрипт), но вам нравится сопоставление объектов, это ДЕЙСТВИТЕЛЬНО круто:

class Student {

    public $id;
    public $first_name;
    public $last_name

    public function getFullName() {
        return $this->first_name.' '.$this->last_name
    }
}

try 
{
    $dbh = new PDO("mysql:host=$hostname;dbname=school", $username, $password)

    $stmt = $dbh->query("SELECT * FROM students");

    /* MAGIC HAPPENS HERE */

    $stmt->setFetchMode(PDO::FETCH_INTO, new Student);


    foreach($stmt as $student)
    {
        echo $student->getFullName().'<br />';
    } 

    $dbh = null;
}
catch(PDOException $e)
{
    echo $e->getMessage();
}

Перемещение приложения из одной базы данных в другую не очень распространено, но рано или поздно вы можете обнаружить, что работаете над другим проектом с использованием другой СУБД. Если вы работаете дома с PDO, то, по крайней мере, вам будет чему поучиться меньше.

Кроме того, я считаю, что PDO API немного более интуитивно понятен, и он кажется более по-настоящему объектно-ориентированным. mysqli чувствует, что это просто процедурный API, который был объективизирован, если вы понимаете, о чем я. Короче говоря, мне легче работать с PDO, но это, конечно, субъективно.

Я начал использовать PDO, потому что поддержка утверждений лучше, на мой взгляд. Я использую слой доступа к данным ActiveRecord-esque, и гораздо проще реализовать динамически генерируемые операторы. Привязка параметров MySQLi должна быть выполнена в одном вызове функции / метода, поэтому, если вы не знаете до времени выполнения, сколько параметров вы хотите связать, вы вынуждены использовать call_user_func_array()(я считаю, что это правильное имя функции) для выбора , И забудьте о простой динамической привязке результата.

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

PDO - это стандарт, который ожидает большинство разработчиков. По сути, mysqli был индивидуальным решением конкретной проблемы, но у него есть все проблемы других библиотек, специфичных для СУБД. PDO - это место, где пойдет вся тяжелая работа и умное мышление.

Вот еще кое-что, что нужно иметь в виду: на данный момент (PHP 5.2) библиотека PDO содержит ошибки . Он полон странных ошибок. Например: перед сохранением PDOStatementпеременной в переменной следует unset()избегать множества ошибок. Большинство из них были исправлены в PHP 5.3, и они будут выпущены в начале 2009 года в PHP 5.3, что, вероятно, будет иметь много других ошибок. Вам следует сосредоточиться на использовании PDO для PHP 6.1, если вы хотите стабильную версию, и на использовании PDO для PHP 5.3, если вы хотите помочь сообществу.

Еще одно заметное (хорошее) отличие от PDO заключается в том, что его PDO::quote()метод автоматически добавляет заключающие в кавычки, тогда как mysqli::real_escape_string()(и аналогичные) этого не делают:

PDO :: quote () помещает кавычки вокруг входной строки (если требуется) и экранирует специальные символы во входной строке, используя стиль кавычек, соответствующий базовому драйверу.

PDO значительно облегчит масштабирование, если ваш сайт / веб-приложение действительно будет работать, поскольку вы можете ежедневно настраивать соединения Master и Slave для распределения нагрузки по базе данных, плюс PHP в качестве стандарта движется к переходу на PDO.

Информация о PDO

Масштабирование веб-приложения

В смысле скорости выполнения MySQLi выигрывает, но если у вас нет хорошей оболочки, использующей MySQLi, его функции, связанные с подготовленными операторами, ужасны.

У меня все еще есть ошибки, но если кто-то хочет, вот оно .

Короче говоря, если вы ищете увеличение скорости, то MySQLi; если вы хотите простоту использования, то PDO.

Лично я использую PDO, но я думаю, что это в основном вопрос предпочтений.

PDO имеет некоторые функции, которые помогают против внедрения SQL ( подготовленные операторы ), но если вы осторожны с SQL, вы можете добиться этого и с помощью mysqli.

Переход на другую базу данных - это не столько повод для использования PDO. Пока вы не используете «специальные функции SQL», вы можете переключаться с одной БД на другую. Однако, как только вы используете, например, «SELECT ... LIMIT 1», вы не можете перейти к MS-SQL, где это «SELECT TOP 1 ...». Так что это все равно проблематично.

Отредактированный ответ.

Имея некоторый опыт работы с обоими этими API, я бы сказал, что есть 2 функции уровня блокировки, которые делают mysqli непригодным для использования с собственно подготовленными операторами.
Они уже упоминались в 2 превосходных (но недооцененных) ответах:

1. Привязка значений к произвольному количеству заполнителей
2. Возврат данных в виде простого массива

(оба также упоминаются в этом ответе )

По некоторым причинам mysqli потерпел неудачу с обоими.
В настоящее время он получил некоторое улучшение для второго ( get_result ), но он работает только на установках mysqlnd, что означает, что вы не можете полагаться на эту функцию в своих скриптах.

Тем не менее, он не имеет привязки по стоимости даже по сей день.

Итак, выбор один: PDO

Все остальные причины, такие как

• именованные заполнители (этот синтаксис сахар слишком переоценен)
• поддержка различных баз данных (на самом деле никто никогда не использовал ее)
• извлечь в объект (просто бесполезный синтаксис сахара)
• разница в скорости (нет)

не имеют никакого существенного значения.

В то же время в обоих этих API отсутствуют некоторые действительно важные функции , такие как

• идентификатор заполнителя
• заполнитель для сложных типов данных, чтобы сделать динамическое связывание менее трудоемким
• более короткий код приложения.

Таким образом, для удовлетворения реальных потребностей необходимо создать собственную библиотеку абстракций, основанную на одном из этих API-интерфейсов, реализующую обработанные вручную заполнители. В этом случае я бы предпочел mysqli, поскольку он имеет меньший уровень абстракции.

В моем тестовом сценарии каждый метод тестируется 10000 раз, и выводится разница общего времени для каждого метода. Вы должны сделать это в своей собственной конфигурации, я уверен, что результаты будут отличаться!

Вот мои результаты:

• « SELECT NULL" -> PGO()быстрее на ~ 0,35 секунды
• « SHOW TABLE STATUS" -> mysqli()быстрее на ~ 2,3 секунды
• « SELECT * FROM users" -> mysqli()быстрее на ~ 33 секунды

Примечание: используя -> fetch_row () для mysqli, имена столбцов не добавляются в массив, я не нашел способа сделать это в PGO. Но даже если я использую -> fetch_array (), mysqli немного медленнее, но все же быстрее, чем PGO (за исключением SELECT NULL).

PDO имеет то, что MySQLi не нравится мне, это способность PDO возвращать результат как объект определенного класса (например $pdo->fetchObject('MyClass')). MySQLi fetch_object()будет только возвращать stdClassобъект.

Есть одна вещь, которую нужно иметь в виду.

Mysqli не поддерживает функцию fetch_assoc (), которая возвращает столбцы с ключами, представляющими имена столбцов. Конечно, можно написать свою собственную функцию, чтобы сделать это, это даже не очень долго, но мне было очень трудно писать это (для неверующих: если вам кажется, что это легко, попробуйте это самостоятельно и не т обмануть :))