Тимлид тащит всю логику в хранимки PL/pgSQL, я считаю это дорога в ад. Рассудите

[kayee]

Ситуация: пришел новый тимлид из банка, и теперь у нас на каждом ревью война. Он хочет, чтобы расчет скидок, движения по балансу и валидация заказов жили в хранимках постгреса. Аргументы: меньше раундтрипов, целостность рядом с данными, и так делают во всех банках. Я против: хранимки нормально не покрыть юнит-тестами, версионируются костылями, дебажить боль, и под нагрузкой упремся в CPU базы, который скейлится только вертикально. Сервис на go рядом скейлится горизонтально за копейки. У нас обычный b2b saas, 14 человек разработки, postgres 16, нагрузка средняя. Бодаемся уже вторую неделю, рассудите.

[mjp1982]

@kayee, Двадцать лет с базами, скажу непопулярное. Движения по балансу это ровно тот случай, где хранимка уместна. Race condition между чтением баланса в приложении и записью ловили когда-нибудь на проде? А я ловил, и разгребал потом минусовые балансы у трех тысяч клиентов. Одна транзакция, один SELECT FOR UPDATE, вся инвариантность в одном месте, и никакой джун из сервиса заказов ее не обойдет. А вот расчет скидок в хранимке это уже перебор, тут ваш тимлид перегибает. Деньги в базу, маркетинг в код.

[seniorwarlock]

@mjp1982, Версионирование решается обычными миграциями, тесты есть pgTAP, это все отговорки. Настоящий аргумент против другой: найм. Найти в 2026 году go разработчика за вменяемые деньги легко. Найти человека, который хочет писать PL/pgSQL, удачи вам. Вся логика в хранимках означает, что вы заложники полутора человек, и когда они уйдут, эту базу никто трогать не будет годами. Видел такое дважды, оба раза кончалось переписыванием с нуля.

[b1llyn0m]

так делают во всех банках это не аргумент. в банках еще кобол местами, тоже потащим?

[mskmkr99]

Истина посередине и она скучная. Инварианты в базу: constraints, уникальные индексы, check, на самое критичное триггер. Бизнес-правила в приложение. База гарантирует, что данные не противоречивы, код решает, что с ними делать. И раундтрипы лечатся не хранимками, а нормальными батчами и тем, чтобы не делать 40 запросов в цикле.

[depechie]

@mjp1982, две недели бодаетесь на ревью. вот это реальная проблема вашей команды, а не хранимки, лол

[svelte42]

Расскажу, чем это кончается лет через десять. Работал в конторе, где 300к строк PL/SQL на оракле. Миграцию с оракла оценили в четыре года и не стали делать. Так и платят за лицензии конским курсом через казахстанское юрлицо, потому что переписать некому, авторы уволились до 2020 года. Логика в базе это решение, у которого цена видна не сразу, но она есть и она огромная.

[ivan21]

@seniorwarlock, придерусь к мелочи, но CPU базы скейлится только вертикально это не совсем правда. читающие реплики никто не отменял, и иммутабельные функции на репликах прекрасно работают. писать да, в одну ноду, но у ТС b2b saas со средней нагрузкой, он в этот потолок упрется лет через пять, если повезет

[lentyaj]

@mjp1982, подниму. у нас ровно такой же спор второй месяц, подпишусь на тред