1) пишется обычный запрос с плейсхолдерами
«SELECT * from mytable where textfield=?»
2) переписывается код проставления плейсхолдеров. тот код, где переменная эскейпилась (и при необходимости оборачивалась в кавычки), заменяется на код, который енкодит значение и возвращает такую конструкцию base64_decode(ЗАЕНКОДЕНОЕ_ЗНАЧЕНИЕ_В_КАВЫЧКАХ)
другого вменяемого варианта не представляю… смысла тоже
Почему это именно placeholders превращают сложный запрос в кашу?
В кашу запрос превращает именно человеческий фактор.
А плейсхолдеры помогут:
а) непозволить этому «человеческому фактору» забыть передать параметр (или передать его криво)
б) «скомпиллировать» запрос (применимо к полноценным БД/языкам программирования) и сэкономить на повторяющихся вызовах с изменением параметров
«SELECT * from mytable where textfield=?»
2) переписывается код проставления плейсхолдеров. тот код, где переменная эскейпилась (и при необходимости оборачивалась в кавычки), заменяется на код, который енкодит значение и возвращает такую конструкцию base64_decode(ЗАЕНКОДЕНОЕ_ЗНАЧЕНИЕ_В_КАВЫЧКАХ)
другого вменяемого варианта не представляю… смысла тоже
Что-то типа:
sql = select('*')->from('table1')->join('table2')->on(...)->where('table1.fied', requestvar.table1.field)->and('table2.field', requestvar.table2.field)->…
Как такой билдер соберет запрос (с плейсхолдерами и последующей передачей значений или сразу все сам правильно заескейпит) — вопрос уже риторический.
В случае же набора статических запросов, плейсхолдеры показывают себя с лучшей стороны.
В кашу запрос превращает именно человеческий фактор.
А плейсхолдеры помогут:
а) непозволить этому «человеческому фактору» забыть передать параметр (или передать его криво)
б) «скомпиллировать» запрос (применимо к полноценным БД/языкам программирования) и сэкономить на повторяющихся вызовах с изменением параметров