Всем привет. Одна компания получила крупный заказ, на объемный, серьезный

проект. Они в поисках архитектора (и команды в целом) под него. Вот уже 2 архитектора предлагают (даже настаивают) на database application подходе, мол есть фронт, кусочек бэка (просто чтоб дёргать процедуры с БД и отдавать json-ы на фронт), а основная логика вся на SQL на процедурах написана. Соответственно ролевая модель тоже внутри самого SQL будет реализована (grand permission и тд).
Т.е. отходим от ООП, DDD, энтерпрайз паттернов.
Мне это кажется диким. Это вообще нормально для крупных проектов, или это устаревший подход? Или я просто устарел в техническом плане?)
Буду рад услышать аргументы за и против такого подхода. Взялись бы вы реализовывать крупный проект (состоит из 10+ подсистем разной сложности) перемещая всю логику на SQL и отказа (почти полного) от слоя бэкенда?
В проекте присутствует и экспорт/импорт, генерация офисных документов, эксель отчетов и тд, интеграция с разными готовыми системами и тд.
p.s. Я слышал что на оракле любят логику прям в SQL пилить.

ужс

Полагаю, у них есть на это какие-то причины?

Кошмар.

да, чем объясняют такое? тем, что потом хер найдешь другого архитекта это саппортить и можно бизнесу руки выкручивать ? =)

Была статья на хабре где такое сделали. Пытаюсь щас найти.

https://habr.com/ru/company/lingualeo/blog/515530/

вы как обычно, преувеличиваете, говоря "всю логику на SQL" никто в такой архитектуре от приложения на условном PHP не отказывается переносится логика валидации и консистентности данных, логика CRUD, контроль и аудит доступа

почему "как обычно"? я был в таком уже замечен?)

не вы конкретно, Алексей а вы, те, кто не понимает DB-driven

Дай угадаю база Oracle ? Проект будет намертво пришит к БД

один рассматривал оракл, 2й MSSQL

И их взломали нахер из за этого

да)))

а можно линку какую-то на эту новость?

https://twitter.com/SanSYS/status/1299657208934916097?fbclid=IwAR23-frJwJHgZA7U4EDtX5o-KZ0Jvanx07ALHeRY1fRJbaip12kmddWzStI

это пять =) теперь я знаю что кидать людям, которые предлагают перенести логику в бд

>ORM не нужно

Ну если кода стало меньше стоимость поддержки снизилась и лид тайм фич улучшился - значит не нужен)

А вообще я как-то гуглил и не нашел какого-нибудь достойного материала с примерами о том что и в каких случаях можно выносить в бд. Мне со своей колокольни так кажется что даже foreign keys не нужны, не говоря уже о ON DELETE CASCAD, триггерах т.д.

foreign keys нужны для доп. гарантий консистентности БД (но тут тоже есть вопросы)

Они редко нужны на самом деле, практика показывает что больше пользы от них для интроспекции схемы. Хотя опять же у меня проф деформация "ничего не удалять"

Я тоже говорил о ситуациях, когда не удаляют. Но экспертиза, несомненно, у меня в разы хуже. Прислушаюсь

Каскады штука коварная. В целом я бы сказал так - если нужно чёт сделать с данными - чистая функция - их вполне удобно делать на sql. Там для этого все средства есть. Триггеры те же у автора статьи не юзаются.