https://www.youtube.com/watch?v=St2iRHOflUo
вот это смотрел?

посмотрю, спасибо

Но не все задачи требуют масштабирования :) Например, надо дважды отфильтровать список гео-объектов, причем вторая фильтрация должна быть различной в зависимости от результатов первой. Это я сейчас придумал навскидку задачу, в реальности у меня такой не было. Но как вы будете без хранимки такое делать, если первая фильтрация возвращает огромное кол-во объектов?

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

Есть же ин-мемори таблицы в запросах
Их можно без хранимки

Если хранимок много, и они используют друг друга сложным образом, то да.
Но если, например, ввести соглашение, при котором хранимки применяются только во внешних вызовах, то большинство описанных вами проблем решаются тем, что при изменениях процедуры текущий код не трогается, а создается новая с новым именем (скажем добавлением постфикса с номером версии). Тогда ее использование прописывание на уровне вызывающего кода (который уже и поддерживаемый и откатываемый и канареечный и т.д.) и в случае чего мы базу не трогаем, а производим откат\тест\накат привычным образом, не трогая базу.

Типа этого

WITH regional_sales AS ( SELECT region, SUM(amount) AS total_sales FROM orders GROUP BY region ), top_regions AS ( SELECT region FROM regional_sales WHERE total_sales > (SELECT SUM(total_sales)/10 FROM regional_sales) ) SELECT region, product, SUM(quantity) AS product_units, SUM(amount) AS product_sales FROM orders WHERE region IN (SELECT region FROM top_regions) GROUP BY region, product;

WITH regional_sales AS ( SELECT region, SUM(amount) AS total_sales FROM orders GROUP BY region ), top_regions AS ( SELECT region FROM regional_sales WHERE total_sales > (SELECT SUM(total_sales)/10 FROM regional_sales) ) SELECT region, product, SUM(quantity) AS product_units, SUM(amount) AS product_sales FROM orders WHERE region IN (SELECT region FROM top_regions) GROUP BY region, product;

А если вам это надо делать при изменении записи в другой таблице? Удобно триггер сделать :)

Ой все)
Я это вспоминаю как страшный сон
Версионирование хранимок в бд
Ещё гит надо на это навесить
И накатывать вместе с кодом...
Как я это любил.. А оно мне мозг..

миграции еще да )

если у вас есть база, то наверное вам иногда надо менять ее схему и иногда вместе с изменениями кода, поэтому уметь менять ее все равно надо
а раз умеете, то в чем проблема донести в базу пару хранимых процедур?
я же не за то, что бы всю логику внутри субд реализовывать, но некоторые вещи вполне

В посгре все тригеры должны генерировать максимум события в очереди для воркеров 'listen - notify'
А логику опять же помещаем в код воркера

Ок
Согласен
Но надо знать меру имхо
Никаких апдейтов и инсертов в хранимках
Все селекты из них только на слейвах

Мой Круг делает обзор зарплат за полугодия, можно ориентироваться на эти цифры + по своему бюджету смотреть.

это по опросам - а надо по замерам. И какое еще мойкруг, он же помер и труп

это лучше чем смотреть вакансии и выводить примерную температуру)
А то что Мой круг умер.... да жив еще, вполне себе)

умер и пахнет..

проще разместить вакансию и посмотреьт кто придёт, чего там выводить. Важно же кто придет лично к тебе на твой офис,задачи, начальника

вопрос звучал так: На какой уровень з/п ориентироваться?
Мы сейчас не о том, кто придет)

Спасибо, я про такое не думал, при случае применю. Но придется смирится с некоторым рассогласованием данных.