Нет, надо именно на сервере. На бекенде это вообще умрет. И мы умеем на С, просто в данном случае не накопилось еще достаточно оснований переехать с RDB на собственный инстанс для базы. Если удастся получить приемлемый результат на PGV8 - то не будем переезжать. Поэтому и спросил - может, кто сравнивал

расскажите почему, а то слишком провокативно звучит.

тебе конкретно про что больше всего интересно?

stored procedure

здесь как то пробегало выше, люди всю БЛ в хранимки кладут и радуются.

Мне тоже интересно.

Заметил что бл в бэкэнд уносят в компашках где даже архитекторы кроме как Селект * больше ничо писать не умеют.)

Во первых вот статья - https://habr.com/ru/post/210920/
Во-вторых, ваши SQL диалекты - обычно это медленная штука со скудными возможностями в операциях со структурами данных.
В-третих - самый жирный минус - как только ваша база не будет в состоянии тянуть количество записей и операций. и вам нужно будет переехать - вы просто охуеете от количества действий которые нужно будет совершить

К тому же если у вас OLTP и иногда вам необходимы аггрегации и иже с ними хранимки убьют вашу БД, самое простое решение - вычисления на бэке

И сколько там действий? Среплицировать с рдс на онпремисес можно вообще то.

Про переезд непонятно совсем.
И про SQL-диалекты тоже...

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

И никакой ебали с селектом 100 строчным

У нас селекты бывают и поболее.

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

>В-третих - самый жирный минус - как только ваша база не будет в состоянии тянуть количество записей и операций. и вам нужно будет переехать - вы просто охуеете от количества действий которые нужно будет совершить

вот это вообще не понял, вы про тюнинг, переезд на другой сервер, или кластер.

в общем пока не понятно.

Не слушай его. О базах человек ничего ровным счётом не понимает. Сначала кладут логику в бэк, потом пандасами, спарками, даксами и воксами пытаются выгрузить и пересечь датасеты как нало на стороне бэка. Хотя одним цте запросом это можно было внутри БД с заведомо более производительным железом сдклать. Мастера.

Я просто вещаю со стороны обычного бэк разработчика столкнувшимся с проблемами основанными на данных фичах

Абсолютно верно ты сказал, я не сведущ так как большинство тут

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

И ты кстати тут не очень прав Более мощное железо >> дороже чем грамотный разработчик + девопс