> этого риска нет в любом случае, если у программиста руки не из Ж растут Он всегда есть, потому что параметры передаются вместе с самим запросом, юзер на них может воздействовать, а соревнование кто кого перехитрит и обойдет на повороте (юзер программера или программер юзера) - практически бесконечное.
> -- он ЧЁТКО пониает границы за которые могут выходить "A" "B" "C" ...
При чем тут вообще границы? Проблема скуля в том что он часто работает с внешними не доверяемыми данными. При том он не делает особых различий между операцией и данными для нее, и позволяет несколько операций в одном запросе. Поэтому без спецмер со стороны программера select из таблицы пользователей легко превращается в например ее дроп или произвольный вызов функционала БД, путем указания имени юзера в стиле того комикса про "little Jonny the tables we call him" ;). Понятно что можно програмера построить, заставить проверять что там ему юзер подсунул и прочая. Тут начинается густое костылирование всякими эскейпами (которые порой мешают жить в легитимных случаях и сажают скорость работы) и соревнование - нащупает ли хакер слабину или нет.
> -- ДОЛЖНА БЫТЬ ПЕРЕДАНА В СООТВЕТСТВУЮЩЕМ ВИДЕ, А НЕ ПУТЁМ ПРОСТОЙ
> ПОДСТАНОВКИ"
В key-value базу можно и путем простой подстановки пхать. Во всяком случае, это не приведет к таким разрушительным последствиям как в скуле.
> # p.s.: я НЕ имею ввиду что программисту нужно *вручную* каждый раз
> формировать "A + B + C".. но понимать как оно формируется
> -- он просто обязан
В случае скуля приходится именно вручную костылить все что может вводиться юзером жесточайшими эскейпами. Совсем не ускоряющими операции, выносящими мозг временами и в результате - скуль-иньекции давно стали привычным классом дыр. А попробуйте в nosql типа ключ-значение чего-то заиньектить вообще? :)
