Хм. А вы вот знали чем отличается обычный мускуль запрос от prepared statement запроса?

Такой вопросик на собесе вот с подковыркой задать )

Только не гуглить. Я сам не знал до сегодняшнего дня

Хм. А вы вот знали чем отличается обычный мускуль запрос от prepared statement запроса?

В контексте php или вне мира php? А то там ответы разные будут

Хм. А вы вот знали чем отличается обычный мускуль запрос от prepared statement запроса?

Что два запроса вместо одного?

Хм. А вы вот знали чем отличается обычный мускуль запрос от prepared statement запроса?

что значит обычный мускуль запрос? пример будет? SELECT * FROM `table` WHERE `name` = 'Уася' такой?

Хм. А вы вот знали чем отличается обычный мускуль запрос от prepared statement запроса?

Prepared подготавливает запрос, а потом хоть 100штук отправь - разбора запроса не будет, будет сразу выполнение

Хм. А вы вот знали чем отличается обычный мускуль запрос от prepared statement запроса?

по большому счёту разница в защищённости

по большому счёту разница в защищённости

Скорее в скорости Защищённости может на стороне либы сделана быть

Скорее в скорости Защищённости может на стороне либы сделана быть

вот вообще насрать, по сравнению с самой операцией это ни о чём

вот вообще насрать, по сравнению с самой операцией это ни о чём

Это если одна операция, а если их куча будет?

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

Это если одна операция, а если их куча будет?

не надо выдумывать синтетические случаи, если реальные про другое

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

Насколько помню, некоторые драйвера эмулируют реальные prepared То есть их нет, а ты даже не знаешь об этом

Насколько помню, некоторые драйвера эмулируют реальные prepared То есть их нет, а ты даже не знаешь об этом

Это про "без переживаний" 😈

В prepared можно пихать спокойно банные Prepared готовится один раз и повторные запросы выполняются быстрее значительно.

Вопрос на котором я завалил сертификацию - что будет, если в prepare отправить запрос с duplicate key то не будет exception

сколько раз я за годы повторно слал подготовленный запрос? ну вот вчера добавлял набору пользователей набор ролей принципиальной разницы с тем, что я сконкатенировал бы в один инсерт нет совсем один инсерт было бы быстрее, чем в n*m но главное - я не парился, что у меня на входе инты

Вопрос на котором я завалил сертификацию - что будет, если в prepare отправить запрос с duplicate key то не будет exception

инсерт игнор

инсерт игнор

не совсем

Да prepared statement парсится один раз и потом можео иего использовать меняя лишь параметры. Но еще prepared statements использует бинарный протокол передачи данных

обычный запрос все данные переводит в строку

Вот это для меня было удивлением

Наверное все клиенты под капотом всеравно используют prepared statement, ну либо гоняют строки по сети

Да prepared statement парсится один раз и потом можео иего использовать меняя лишь параметры. Но еще prepared statements использует бинарный протокол передачи данных

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

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

просто это еще дополнительно тратится процессор на перевод всего в строку

помимо размера пакета

если у тебя куча чисел например

ведь хранится оно не в виде строки

Вот на счет скорости

https://www.php.net/manual/ru/pdo.prepare.php#114616

еще бы сравнить такой цикл с препаред и обычным

вот что сказано по поводу обычного запроса

A row with the data for each column. NULL is sent as 0xfb everything else is converted into a string and is sent as Protocol::LengthEncodedString.

а давайте ещё проверим, как быстрее массив на пустоту проверять

а давайте ещё проверим, как быстрее массив на пустоту проверять

И кавычки 😂

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

ну в самом деле, было бы оно чутка медленнее, я бы всё равно писал так

особенно меня веселит когда используют обычный джсон зато пишут типо { "A": 123, "B": "some_data"}

а ты сиди и думаб что такое А и Б

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

а ещё мы обмазываемся валидаторами, а могли бы просто доверять вводу, ага

О какой безопасности вы вообще говорите, если на сервер базы данных всё равно уходит 1 запрос? Нет смысла говорить про “безопасные запросы” в контексте PHP, поскольку драйверы это не умеют 🤷‍♂️

О какой безопасности вы вообще говорите, если на сервер базы данных всё равно уходит 1 запрос? Нет смысла говорить про “безопасные запросы” в контексте PHP, поскольку драйверы это не умеют 🤷‍♂️

тут должна быть картинка про Бобби брось таблицу

безопасность наверное имеется в виду экранизация?

безопасность наверное имеется в виду экранизация?

Экранирование😂 экранизация PHP пахнет порно

но тут кстати я не вижу ничего в доке про экранизацию prepared statement так что возможно она далется клиентом автоматичеки

сорян да экранирование )

вообщем если у вас какой-то микросервис который крутится в фоне и не умирает, я бы всетаки юзал prepared statements

не тратится время на парсинг запроса

ну как бы да, но это накопление стейта и требует дисциплины

$queryObject = $this->connection->prepare( 'INSERT IGNORE INTO users_roles (user_id, role_id) VALUES (:userId, :roleId)' ); foreach ($userIds as $userId) { foreach ($roleIds as $roleId) { $queryObject->execute(['roleId' => $roleId, 'userId' => $userId]); } }

Еще лайфхак, если нужно очень много делать инсертов, там есть настройка, как часто делать flush на диск. Если увеличить эту опцию, то скорость возрастает в разы

Но правда и риск потери

безопасность наверное имеется в виду экранизация?

Под безопасностью имеется ввиду работа подготовленных запросов так как они должны работать. Может я чего не знаю из обновлений драйверов под базы данных на PHP, но в классический prepared statement они не умели. Выше писали про то что они всегда делали эмуляцию и не более

Я так тюнил мускуль для счётчика посещений. Работало очень быстро

Под безопасностью имеется ввиду работа подготовленных запросов так как они должны работать. Может я чего не знаю из обновлений драйверов под базы данных на PHP, но в классический prepared statement они не умели. Выше писали про то что они всегда делали эмуляцию и не более

Думаю уже умеют

Давно ведь уже существуют

Они давно это эмулируют и у меня нет оснований полагать что что-то поменялось

Просто я изначально задавал вопрос — “В контексте php или вне мира php? А то там ответы разные будут” То что я знаю про драйверы под PHP — они всегда эмулировали функционал prepared statement и, в принципе, никогда этого не скрывали. Под эмуляцией имеется ввиду что не осуществляется следующее: prepared statement отправляет строку запроса и то что в нём должно исполняться — в двух разных запросах в базу. Первый дает возможность составить план запроса, а второй его исполнять. В мире драйверов PHP prepared часть не осуществляет запрос в базу. Выжимка из коммента к методу PDO::prepared() — Emulated prepared statements does not communicate with the database server so PDO::prepare does not check the statement. Ок, эмулирование не ходит на сервер базы, логично. Но при этом сам PDO по умолчанию создается с флагом PDO::ATTR_EMULATE_PREPARES => false — что якобы значит что никто никогда и не включал эмуляцию 🤷‍♂️ Вы можете провести исследование и потыкать PDO с флагом PDO::ATTR_EMULATE_PREPARES в разных значениях. И узнать сколько и каких запросов уйдёт на сервер базы данных

В догонку в контексте базы, для нормальной работы с prepared statement по хорошему важно уметь делать не только сам PREPARE а и DEALLOCATE PREPARE, но, насколько я знаю, таких механизмов в мире PHP нету. А потому даже если в каких-то конфигурациях, с какими-то базами, с какими-то драйверами у вас и получится сделать prepared statement, то нормально работать с таким в ближайшее время у вас не факт что получится. Ну или я чего не знаю и тогда с удовольствием послушаю какие-то новости или инсайты. Потому, как по мне, ответ на вопрос “Чем отличается обычный мускуль запрос от prepared statement запроса?” — В мире PHP ничем не отличается 🙂 а в остальных случаях отправляет sql-выражение и данные для него в двух отдельных запросах на сервер базы данных

DEALLOCATE сделается автоматом когда конекшн сдохнет

он в скоупе конекшена находится

так что тут проблем нету

утечек не будет

DEALLOCATE сделается автоматом когда конекшн сдохнет

Тоже слышал такое, но не уверен что это работает для всех популярных баз, это во-первых, а во-вторых, что делать с persistent connection? Не то что бы прям хорошо просто так разбрасываться ресурсами и плодить соединения

связь m2m в доктрине InverseJoinColumn.referencedColumnName отлично работает для выборки но при сохранении игнорирует и записывает id вместо monolith_id кто сталкивался с таким?

Всем привет. а как правильно склеить OAuth и jwt?

Есть бандл от php league - oauth server

Там уже есть jwt. Или речь про клиент?

ну вообще задача авторизоваться черещ oauth а потом это все переправить в мобильное приложение с jwt

Есть бандл от php league - oauth server

да, он у меня стоит и сою функцию выполняет, вот придумываю как это все с мобилкой завязать.

А в чем требла. Jwt токе можно сгенерировать руками и отдать токен клиенту после успешной oauth авторизации

А в чем требла. Jwt токе можно сгенерировать руками и отдать токен клиенту после успешной oauth авторизации

да пока ни в чем, я этого никогда не делал. разбираюсь как раз

интересную статью нашел https://habr.com/ru/company/vk/blog/417031/

А лучше просто прикрути jwt рядом с oAuth

Юзер у тебя есть, отсалось только jwt прикрутить

И не городить огород

Чем сложноее система тем больше в ней дыр

да вот как раз огород городить не хочу. oauth дает мне юзера с данными из внешней системы. дальше его надо как то авторизовать. пока не понимаю как.