Очередной срачъ, у zabivator-а

[metaclass]

Я всегда думал, что может заставить людей не использовать связываемые параметры в запросах и извращаться с самостоятельной конкатенацией запросов, проверкой на sql-инъекции, эскейпингом, обработкой локалей и форматов и прочим садомазохизмом при работе с СУБД.
Оказывается, bind-параметры влияют на производительность.

То, что он формально прав, и что, зная значения параметров, СУБД может выбрать более оптимальный план, не меняет того факта, что это сродни ассемблерным вставкам и экономии на количестве переменных на стеке при разработке опердени, чтобы "работало быстрее".

Я счас поискал в гугле про подобные проблемы - у людей с OSM подобная фигня с бинд-параметрами в Postgresql вылезла. Но это на таблице в 500 млн записей и очень хитрожопном запросе. Предполагаю, что с такими объемами на обычной опердени жопа начнется намного раньше, чем разница между планами хоть как-то повлияет.
Не говоря уже о том, что правильный план можно прибить гвоздями, как минимум в Firebird так точно и вообще не мучится.

Comments

[dmitry-vk.livejournal.com]

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

[zamotivator.livejournal.com]

Естественно, мы просто перестраиваем запрос.

Да, для веб-приложений это всё мышиная возня, если подумать. Для того и посоветоваться пришёл.

Кстати, а bind-параметры 100% предохранят от sql-injection?
Я вот не могу придумать, как они могут протекать, но как бэ бережённого бог бережёт

[dmitry-vk.livejournal.com]

bind-параметры никогда не подвергаются синтаксическом анализу, они никак не могут изменить структуру запроса, поэтому инъекция кода исключена 100% (патологические случаи вроде использования аналога eval не берем в расчет).