Большие биллинги, банковские системы все сидят на оракле с логикой в БД. В первую очередь из-за требований СБ.

Сторонний инструментарий разработчика вполне поддерживает версионность кода и совместную работу.

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

Это флаг любителей СПО и модульности. Но в реальном мире телекома и банков, особенно лет 10 назад, все было совсем не так.
Если тебе надо задним числом перетарифицировать сотни миллионов звонков за разумное время, то путь один - процедуры внутри БД.

Процедуры внутри БД - это одно. Вся бизнес логика внутри БД - это другое.

+

Логика внутри БД рождается по тем же причинам - необходимость контроля доступа к данным

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

Мотивация от Торшиной (остороно: неполиткорректно)
Как отличить быстрее всего человека старой закалки от представителя инфантильного нового поколения?

Очень просто — дать человеку пизды. Ну не на пустом месте, конечно, а выбрать момент, чтобы было за что, хоть чуть-чуть.

Даёшь пизды человеку из стареньких — он может уже через час включить пятую скорость и выдать тебе такие результаты на дымящейся жопе, что ты обалдеешь.

Даёшь пизды молодому — уходит страдать. И страдает, либо пока ты не извинишься за то, что дал пизды за то, что он хуёво работает, либо пока не уволится сам («я решил поискать себя в...»). Ну либо пока в его норку не придёт психотерапевт с фуфломицинами или другая мамочка с другим сладким чаем.

Стабильность сотрудника — вот самое охуенное качество для работодателя. Потому что ты уверен, что что бы ни случилось (Украина, Трамп, корона, конституция, дождь, снег и пр.) — твой человек встанет, позавтракает, придёт и сделает, что должен.

Читать статью полностью здесь: https://torshina.me/pizdaboliya/kak-effektivno-rabotat-v-usloviyax-agressivnoj-vneshnej-sredy/

Ассоциация:

Бригадир у нас хороший,
Бригадир у нас один
Соберёмся всей бригадой
И п###ы ему дадим!

Стабильность работодателя — вот самое охуенное качество для сотрудника. Потому что ты уверен, что что бы ни случилось (Украина, Трамп, корона, конституция, дождь, снег и пр.) — твой работодатель встанет, позавтракает, придёт и заплатит тебе зарплату.

Как так, ведь материальная мотивация - не главное!

Как говорит нам HR

😂

+

А давайте похоливарим немного.
Вводные: учет в 1С, отчётность в 1С.
Нужен интернет магазин на 10-12 000 товаров. Первое что приходит в голову Битрикс
Может ещё какие мысли?

Мы эксплуатировали одно прекрасное решение для учета ПИФов написанное в парадигме: вся бизнес логика в базе, буквально.
Первое на что хотелось бы обратить внимание: очень плохой сиквел под капотом. Прям видно - вот тут нагенерили, вот тут накостылили, вот тут глупость написали. И все медленно и печально.
Второе - обновления. Ни одно обновление от вендора не накатывалось нормально. Всегда были приключения и потери данных. В конечном итоге перестали накатывать обновления. Т.к. смысла особенного не было. Вендор на год-два опаздывал с апдейтом  по изменениям законодательства.
Третье - боль интеграции. Да нет никаких способов интегрироваться с таким решением, по мнению вендора ;).
Безопасность... Ну-ну. Ничего кроме улыбки, когда запрос по клиенту возвращает еще немного другого клиента. Магия наверное ;)

Закончилось тем, что переехали на решение другого вендора.

Выводы которые я сделал: БД - это хранилище в первую очередь. И пока есть возможность не надо на бд дополнительную ответственность навешивать. Если вы не Tier 1 оператор, то вам скорее всего вообще нет необходимости сегодня бизнес логику в бд тащить.

Про СБ. Судя по тому как мошенники чистят банки, сливают клиентские данные и прочие непотребства творят - безопасники делают что то не так. Возможно бумажками уже нельзя периметр защитить.

Если разработчик ПО не умеет пользоваться средствами СУБД и не понимает как они работают, не знает что умеет СУБД, и не имеет ни малейшего представления как работают процессоры, ОС и дисковая система - получается вот такое как написано.

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

"Если процессоры нагружены на 20% - уже тормозит, давайте возьмем побольше.
NUMA? Что такое NUMA?"

Есть такое замечательное поделие IBS SoftSolutions так вон оно не делает вложенные запросы, и не использует временные таблицы, оно генерит таблицы, в них делает селект и пошли дальше, а в конце транзакции оно грохает эти таблицы.
На мой вопрос «охренеть, а зачем?» они отвечали «ну если транзакция умрет в середине мы всегда по оставшимся таблицам поймём почему сдохло»