> Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный
> код при правильной его организации.

Тем не менее, это дополнительные действия. Если данных много, их экранирование/деэкранирование может занять вполне заметное время. Хороший k/v вообще хранит любые данные. Что означает отсутствие таких проблем by design. Намного лучше когда дизайн failsafe сам по себе, да еще и скорость не просядет лишний раз.

> Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано),

С таким же успехом можно говорить и о обратном переходе там где SQL запихнули "потому что модный buzzword же". И тут вдруг ВНЕЗАПНО до некоторых стало доходить что NoSQL может быть инересной опцией в плане скорости :). В основном потому что там геморно делать неоптимальные запросы.

> то скорее всего все запросы изначально будут в виде prepared statements, и
> никакого явного экранирования не потребуют.

Не, куча допущений - это здорово, конечно, но я не вижу - что даст такой маневр в общем случае кроме лишнего головняка и тормозов. SQL достаточно сложный ЯП, грамотно делать запросы на оном умеет очень небольшое количество народа. А чтобы оно еще и работало со скоростью хоть немного похожей на оную у key-value баз - это вообще рокетсайнс.

Я конечно понимаю рвение везде пихать SQL, но обычно как раз это приводит к тому что его пытаются сосватать даже туда где он нафиг не упал. А потом начинаются удивления - "ой, как это - файрфокс начинает тормозить если вы много сайтов посетили?!". И догадайтесь, блин, во что оно уперлось. В сиквельную базу, итить. Во как.

>> Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами.
> В .ru вообще много примеров использования разных вещей безмозглыми существами... но это
> ни о чем не говорит.

Хорошо, я могу и иной пример. А вот в амарок2 активно сватали мускуль. Я например совершенно не понял зачем мне в системе здоровенный демон от навороченной базы и просто снес все это безобразие нафиг. Они бы еще пэхэпэ и апач приволокли, блин.