Костян что тут сказать, раньше я не знал что это такое, теперь знаю что бяка для меня там все новое так что своего мнения пока не имею)
Статью не читал, а просто из опыта: оно там есть, потому что это можно было сделать. Prepaired statments в PHP толком даже не нужны по той простой причине, что многий SQL складывается из кусочков динамически. Они нужны в языках со строгой типизацией, где манипуляция данными существенно ограничено, к тому же там подход к программированию совсем другой.
на самом деле ничем, ибо у меня так и работает QueryObject с использованием PS... а вот это 100%-ный аргумент и еще объясните мне в чём лажевость тестов? Потому, что нагрузка нагрузка не учитывается, параллельность и всё такое? В чём тогда будет разница в других и моих результатах? Только конкретно!
Psih Я не вижу никакой логической связи между prepared statement и динамической сборкой запроса. Одно другого не заменяет и не исключает. Мсье не соблаговолит ли раскрыть полет своей мысли?
Объясняю. Как минимум: 1. ты не выяснил - как работают подготовленные запросы в многопользовательской среде. (как они влияют на скорость работы при одновременных обращениях нескольких пользователей) 2. ты не выяснил - как влияет сложность запроса. И при этом ты делаешь какие-то выводы с непонятными цифрами в руках, которые являются единственным твоим аргументом... О чем можно дальше говорить?
Simpliest Когда SQL cоставляется динамически, то и кол-во подстановок может быть весьма разным, не говоря уже о их разношерстности. Это обстоятельство часто сводит преимущества prepared statments на нет, делая их использование весьма неудобным. Я пытался использовать их в своём проекте текущем, не получается.Часто приходится городить слишком много кода, гораздо проще подставить ID напрямую с приведением к int. А множественная вставка? Я это делаю одним запросом, обычно по 100-150 записей за запрос. Как это сделать через prepared statments? Тока в цикле выполнять запросы поштучно, за что сервер вам спасибо точно не скажет. Я не говорю уже о том, что в MySQL они обрабатываются на сервере, т.е. делая один prepared statments фактически делается два запроса к базе - собственно сама подготовка, а потом данные. Хорошо посещаемый проект вам спасибо за это точно не скажет. Единственное действительно удобное применение - это работа с blob данными, где вы можете просто через API указать что загрузить в базу для prepared statment запроса. Вот тут да, однозначный +, т.к. можно грузить хоть мегабайты потоком, не нужно формировать громадный запрос для отправки на сервер. Но задачка то не из частых и весьма специфична.
Ну и что это за поток сознания? Или это была аргументация? В чем проблемы? Чем именно динамическая сборка запроса мешает? Я в упор не вижу сложностей, на которые вы умудрились напороться. Не знаете как сформировать запрос с произвольным числом плейсхолдеров? Не имеете представления как проконтролировать эквивалентное число входящих параметров? Или что? Где лежат те грабли незнания, которыми вы получили по лбу? Не надо нам голословных заявлений. Костян именно с них(почти дословно) и начинал. Когда ему сказали что этого мало, он худо-бедно провел тесты. Да, они неадекватны, но они хотя бы есть. Где ваши цифры?
+1 Simpliest а зачем они при динамческой сборке запроса? в таком мероприятии проще будет добавить ещё пару конкатенций =)
как они работают?! точно так же они и работают - два обращения к серверу, дающие падение производительности в полтора раза. Вот попробуй сам с той же ab.exe хотя бы! какую сложность ты имеешь в виду?
дам тебе маленький намек - попробуй включить persistent connections, увеличить размер кеша разобраных запросов, и внезапно ты получишь противоположный результат. Попробуй сменить тип таблиц на innodb, задействовать foreign keys, сделать СЛОЖНЫЕ запросы с джойнами - и получишь разницу в 200% сверху. Твои тесты ничего не значат, потому что измеряют, но ничего не сравнивают.
так это другой вопрос, как бы. где он находиться, за какими настройками, можешь сказать? Ну вот, опять какие-то домыслы. Я как нибудь попробую. Возможно вы и правы я не хочу, и не могу ничего сказать в упрёк, но обычно запрос выполняет сервер, а не библиотека передачи данных. Короче посмотрим ))
Правильно. Вот в этом - наше все. Проигрнорировать все написанное по делу и прикопатся к ОЧЕВИДНО взятому с потолка числу. Хорошо, читай 200% как "много". Легче станет?
Олег, ничего личного, я за объективность, если повсеместное PS в приложениях это быстрее, то пусть будет так. Я показал свои тесты, а ты мне говоришь - хуйня, вот надо СЛОЖНЫЕ запросы. Я аргументирую простыми измерениями, ты - ничем не аргументируешь. Какой то там кешь подготовленных запросов? Где оно, хрен его знает. Никто не может сказать есть ли он на самом деле. Если ты скажешь то я только обрадуюсь разрулению ситуации. Только сказать надо не "он есть", а вот смотри url. Понимаешь?
Ну так когда я чего то не знаю, я не пишу статьи, и не спрашиваю чужого мнения. Ты спросил мнения? Ты его получил, в чем проблема-то? Я назвал тебе то, что ты не учитываешь, но что сильно влияет на показатели ТВОЕЙ обсуждаемой темы. Я считаю, это достаточно конструктивно. Проблема в том, что ты не очень-то представляешь себе механизм того, что ты собственно, меряешь. Для тебя подготовленные выражаения это "что то вроде таких буковок в скл что бы не эскейпить переменные". И аргументация на уровне оной. С тобой пытаются завязать дискуссию - ты отметаешь все доводы, которые тебя не устраивают, и принимаешь все, которые совпадают с твоей точкой зрения. В результате твои тесты измеряют лишь одно - насколько медленней подготовленные выражения чем линейные запросы в придуманных тобой условиях