Я должен действительно использовать PDO и подготовленные операторы?

Мне очень нравится PDO интерфейс. Как только вы привыкнете к нему, он станет намного чище, чем стиль функций mysql_*. Мне тоже понадобилось время, чтобы понять это, но оно того стоит.

Часть, которую я нашел запутанной, заключалась в том, что я вспомнил, какие методы принадлежат самому объекту подключения БД PDO, а какие являются частью объектов оператора.

При выполнении определенных действий вы получите выгоду от повторения подготовленных утверждений. Например, если вы делаете кучу вставок в цикле, вы можете подготовить оператор, а затем каждый раз привязывать новые данные в цикле перед вставкой.

Безопасность тоже гораздо лучше в том, что Вы полагаетесь на хорошо протестированную библиотеку, чтобы избежать попадания Ваших данных на каждую вставку. Это как криптография - зачем делать это самому, если это что-то настолько важное? Нет причин давать себе шанс ошибиться (т.е. случайно пропустить бегство от чего-то, вставленного в запрос).

Я рекомендую это руководство для PDO, от автора, который написал эту великолепную гигантскую книгу о Mysql .

Мне нравится использовать стиль позиционного параметра, а затем вы просто делаете массив данных и передаете его. Мои запросы выглядят как

$pdo_db=pdo_connect('cow_db');
$sql='select this,that,count(those) as snout from lovely_table where name=? and horses=?';
$data=array($username,$horse_count);

$query_stmt=$pdo_db->prepare($sql);
$result_handle=$query_stmt->execute($data);

//then I have a function to load data from the result handle
$info=load_array($result_handle);

Вы могли бы заставить такие функции работать со стандартным интерфейсом mysql php, но почему бы просто не использовать PDO?

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

Если вы хотите узнать больше о том, как создать простую подготовленную оператор, посмотрите в функцию SPRINTF . Вы просто замените любые переменные строки, целые числа и т. Д. С спецификатором типа (в этом случае % s и % D соответственно).

Так что, например, в следующем запросе, я знаю, что ID будет целым числом (он будет численным) и имя будет строка (буквенно-цифровой).

$username = 'Simon';
$id       = 3;
$query    = "SELECT FROM `users` WHERE `id` = {$id} AND `name` = '{$username}'";

Если я получаю либо из этих переменных, от неверного источника (например, пост / получить), то я могу убедиться, что они являются правильными типами данных, заменяя окончательную строку (набор запросов $) SPRINTF Как это называется:

$username = 'Simon';
$id       = 3;
$query    = sprintf( "SELECT FROM `users` WHERE `id` = %d AND `name` = '%s'", $id, $username );

SPRINTF просто не позволит мне использовать строку для $ ID или целое число для $ name, когда его называют, что обеспечивает правильные типы данных. (Это дает мне это немного дополнительной безопасности). Если приведены неверные типы данных, то , я полагаю , это будет переменные переменные запрошенному типу.

Подробнее о SPRINTF Визит здесь: http://php.net/sprintf

Я надеюсь, что это объясняет (это мой первый ответ) :).

Вы можете попробовать zend_db, который использует PDO под капотом. ( MDB2 - другой вариант, который вы можете использовать.)

PHP позволяет вам сделать все, что вы хотите, и это просто так, PDO делает то, что «вы хотите» с гораздомым кодом. :)

Я согласен с другими, которые говорят, что использование подготовленных запросов, как правило, лучше, чем использование эскапающих функций. Проще правильно использовать, и нет никаких способов значения параметров вводить проблемы впрыска SQL, поскольку значение отправляется на сервер RDBMS отдельно от запроса SQL.

Тем не менее, использование параметров полезно только тогда, когда динамические части вашего запроса SQL являются параметром вместо буквального значения в выражении. Вы не можете использовать параметр запроса вместо имени таблицы, имя столбца, выражения SQL или список значений (например, аргументы в () ).

Подготовленные запросы также имеют лучшую производительность , чем не подготовленные запросы (по крайней мере, в MySQL). Большинство людей говорят наоборот, но уважаемый MySQLPERFARCEBACEBLOG.com сделал тестирование:

http://www.mysqlperformanceblog.com/2006/08/02/mysql-prepared-stations/