Подготовленные запросы

Нужно ли в подготовленных запросах (prepare statements) использовать кавычки при составлении запроса? Например:

1) http://forum.php.su/topic.php?fo...33&topic=771
2) да.

-----
Шта? Репозиторий?

Т.е. можно и с кавычками, но нежелательно?

Еще такой вопрос: является ли код ниже правильным построением подготовленного запроса, чтобы избежать SQL-инъекций?

нет не нужно, они для строк они ставятся сами

Да, правильнее именно второй вариант. Суть подготовленных запросов это убрать все значения за пределы запроса. Даже если вы знаете что значение полностью безопастно (сами его генерируете, а не берёте от пользователя), то всёравно лучше вынести его из запроса, такое разделение более правильное.

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

Спасибо за помощь.

Выносят всегда вот почему.

Даже сама фраза "подготовленный запрос" уже намекает, что запрос подготавливается.
Что значит подготавливается?
Он валидируется синтаксически (только в контексте SQL без учета данных, которых еще и нет).

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

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

Успешно подготовленный запрос, если это делалось прямо на клиенте (в драйвере), вместе с подставленными данными (эскейпинг которых проходит в драйвере(?)) отправляется наконец в базу для выполнения.
А если подготовка проходила уже в базе, то успешно подготовленный запрос лежит в памяти базы и ждет от нас данные для подстановки.
Т.е. мы отправляем только данные (эскейпинг которых проходит в драйвере(?)) для подстановки.

И тут наконец сам запрос и выполняется.
И во время выполнения уже точно никаких ошибок не возникнет.
И мы можем быть уверены что получим результат.
Даже если мы получим ноль строк -- это результат на основании условий запроса.

Ну да, для инсертов или апдейтов конечно может произойти ошибка во время выполнения.
Например попытка дублировать уникальный ключ. И все такое.
Но это уже мелочи.

З.Ы.: Хренасе я тут расписал ))

-----
Шта? Репозиторий?

И вот тут-то начинаются проблемы.
Потому что оптимальный план запроса зависит очень сильно от данных. Банально: табличка на лям записей, запрос where created_at between ? and ? and user_id=?, есть два индекса (не уникальные): по created_at и по user_id.
Ну и какой план будет оптимальным? Да фиг его знает. Может, попросим найти крайне редкий user_id - искать надо по его индексу и отсеять по дате. Может, по узкому диапазону дат будет лучше - возьмём индекс по датам. А вдруг мы запросили огромный диапазон дат и этот юзер занимает практически всю таблицу? seq scan окажется быстрее рандомного доступа по индексам.

Ближе к практике:
В mysql prepared statements завязаны на сессию. При завершении сессии подготовленные выражения забываются. Кэшируется ли сам план запроса - сомневаюсь, но точно не знаю.
В postgresql подготовленные выражения живут в work_mem. Следовательно, новый коннект к бекэнду - подготовленные запросы будут обрабатываться заново. Поскольку профиль короткоживущих запросов от PHP и форковая архитектура postgresql вместе живут отвратно, ставится прокси и этот прокси должен так же уметь подготовленные запросы. За остальные не скажу, а pgBouncer в режиме транзакций в принципе не может работать с подготовленными выражениями. Хотя в режиме сессий вроде умеет, на конкретную сессию. Но это куда печальнее режима транзакций. На моём текущем проекте используется pgBouncer в режиме транзакций и PDO::ATTR_EMULATE_PREPARES => true.
В oracle планы запросов кэшируются и получаются как раз большие костыли с попытками базы понять, когда этот план ещё актуален, а когда его лучше переделать. Подробностей не знаю, лично с ораклом не работал.


Нигде не проходит. Это специальный бинарный протокол для отправки данных. Что-то вроде: база, привет. Помнишь, я говорил о таком-то запросе? Так вот, выполни с параметрами: следующие 8 байт - это параметр 1, потом 200 байт параметра 2.

-----
PostgreSQL DBA

Ааааа, точняк, профукал! Эскейпит только если собирает по старинке строку на месте. А тут бинарщина улетает, конечно.

-----
Шта? Репозиторий?