А откуда известно, что там точно есть возможность для injection?  Или это в смысле - "повышенная вероятность"?

сами не проверяли, это предположение

мне понравилось, что автор в статье говорит про "всё стало летать", а на деле, ответ за 4.5 - 5.0 сек

тем не менее ребята получили бесплатный многокомпонентный (но не полный) аудит их системы

и теперь они (и не только они) знают свои узкие места

С логикой в БД много всяких проблем. Я уже не говорю про релизный цикл, тестирование, откаты обновлений. Рефакторить не удобно, дизайнить вообще невозможно. Те кто не дизайнит, им всё равно, они таких проблем не понимают.

Как масштабировать такую логику? Только вместе с БД. Видимо, не упёрлись пока в предел масштабируемости.

Даже читать не хочется такие статьи. Явно авторы что-то не учли, что-то недоговаривают. Логика в БД - пройденный этап. Если конечно, мы не говорим про аналитические задачи, ряд которых можно решать на данных в инмемори бд.

про версионирование, оригинальный ответ от создателей системы можно увидеть на примере названия процедуры api_set_user_profile_v5

Рано или поздно, по мере разрастания логики в базе будут адовы скрипты на десятки страниц. Если таких скриптов нет, значит пока что решение ещё очень простое.

Средства структуризации большого объема логики в БД есть. Но вот следить за этим....  Впрочем, точно также надо следить за тем, чтобы в ООП-решении не было методов на тысячу строк и god-классов, если вы работаете с толпой junior'ов.

Некоторые энтузиасты работают над тем, чтобы раскладку Event Storming автоматически преобразовывать в код. Посмотрим, что у них получится. Там, конечно, есть вопросы по их реализации, но пока рано делать выводы. Технически это может сработать.

Вот именно, как следить. Ну ладно, допустим привыкли писать PL на тысячи строк. Как масштабировать это?  Нужно понимать, что когда код исполняется в среде данных, то маштабировать можно только среду данных, то есть СУБД. А СУБД работают на дорогом железе с СХД, то есть СУБД масштабировать всегда дорого.

Да никак. на эти грабли 20 лет назад наступили уже все кому не лень. И перестали так делать.

Поэтому и пишу, что даже обсуждать не хочется пионерские очерки.

Нет, ну теорети-и-ически можно разделить на как бы "бд данных" и "бд логики" и масштабировать отдельно....

Но смысла в таких упражнениях не вижу

Всегда хочется (мне?), чтобы критика была разумной, а не "вообще все - г". Масштабирование по производительности - понятная критика. Управление сложностью - уже есть вопросы. Injections - не очень ясно, почему вдруг повышенная вероятность.

Гланды должен вырезать ЛОР, а не проктолог

Нет, всё нет так. Не имеет смысла обуждать то, что уже обсудили давно.

Моя главная претензия - "моральное устаревание" арх-паттерна. Хотя некоторые с большим трудом признают, что это вообще плохо. Еще согласен с бедной инструментальной поддержкой (например, отладки), и как следствие - вероятным повышением дефектности и трудоемкости.

injection я бы сказал не повышенная вероятность, а максимальная величина <вероятность>*<масштаб потерь> - одна единственная уязвимость обеспечивает утечку вообще всего

С другой стороны, и следить нужно за меньшим количеством периметров, но это более слабый аргумент, чем отсутствие диверсификации

В медицине давно пришли к тому, что гландами занимается ЛОР, а не проктолог. Когда очередной проктолог вырезал гланды через место, за которое он отвечает, заново обсуждать этот вопрос смысла нет. Это не ноу хау, просто кто-то что-то не учёл или не знал. Это должен делать ЛОР и точка.