Бизнес логика в хранимых процедурах СУБД. Ваше мнение.

Понимаешь, crutch_master - ты сунулся на работу в расчетный центр, на чисто СУБД-шный проект. И проблема здесь совсем не в том, что твои коллеги работают «по старинке». Здесь реляционная СУБД-шка со всеми её плюшками - это наиболее адекватный инструмент для программирования (а вовсе не Java). Здесь нужно держать в голове всю схему базы данных. А тебя воротит от SQL и реляционного стиля мышления - ты не хочешь всё это осваивать в полной мере. Поэтому тебе исходники встроенных процедур кажутся «страшными» и нечитабельными.
Ну так найди себе другую работу. Или уж пересиль себя и попробуй освоить в полной мере еще один весьма полезный инструмент.

А вся эта дискуссия, которую здесь развели те, кто «за» и «против» - она в том виде, как это здесь происходит, совершенно бессмысленна.

Здесь нужно держать в голове всю схему базы данных.

Зачем же сразу всю?

Здесь реляционная СУБД-шка со всеми её плюшками - это наиболее адекватный инструмент для программирования (а вовсе не Java).

Она не адекватна, потому что чтобы посчитать if (c) then a+b else a-b нужно делать всякие нетривиальные вещи, потому что a b и с берутся какими-то подвыборками. Всё становится еще интереснее, когда к тебе приходят бухи и спрашивают почему у тебя там a+b, а не a-b, почему там a и b именно такое, а не какое-то другое.

А тебя воротит от SQL и реляционного стиля мышления

На прошлой работе я вполне себе угорал по sql и всё было норм и на хранимках.

А вся эта дискуссия, которую здесь развели те, кто «за» и «против» - она в том виде, как это здесь происходит, совершенно бессмысленна.

По крайней мере вчера я отвлёкся от больного зуба, узнал/вспомнил про воркеры в ноде, узнал что представляет из себя функция в питоне...

Здесь нужно держать в голове всю схему базы данных.

Зачем же сразу всю?

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

Она не адекватна, потому что чтобы посчитать if (c) then a+b else a-b нужно делать всякие нетривиальные вещи, потому что a b и с берутся какими-то подвыборками.

Ну и чем тебе поможет здесь программирование на стороне клиента? Собственно, в хранимых процедурах у тебя практически та же свобода действий (можно даже курсоры задействовать - чем на клиентской стороне нонче пользуются редко). Исключение, это когда действительно бывает выгодным по времени предварительно закачать какие-то более-менее агрегированные данные в оперативную память - в какие-то собственные промежуточные структуры хранения - и там уже выполнить окончательное вычисление над этими данными. Но это же редкость...

Всё становится еще интереснее, когда к тебе приходят бухи и спрашивают почему у тебя там a+b, а не a-b, почему там a и b именно такое, а не какое-то другое.

А это уже вообще другая песня ) Общение с бухами и работа в финансовых организациях вообще вредна для здоровья )). Я, например, поработал в нескольких банках программистом и админом - насмотрелся... меня туда никакими деньгами больше не заманишь. Серверным/DBA-админом еще как-то можно, а программистом - это вообще капец.

А это уже вообще другая песня ) Общение с бухами и работа в финансовых организациях вообще вредна для здоровья )).

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

Серверным/DBA-админом еще как-то можно, а программистом - это вообще капец.

Так а где работать? Везде же бухи так или иначе.

Чем больше логики сможешь перенести в БД, тем лучше.