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

У хранимок есть минимум джва жирных минуса:
1. Они не DB agnostic // Хотя нахрен не нужно в 95% случаев
2. Их сложно тестировать и следить за их изменением
Душа олдфага разделяет желание пописать логику на теплом ламповом (plpgsql? pl-sql? не важно, они все теплые), но посмотри как нынче модные архитектуры построены. 10 сервисов возвращают по плоскому списку сущностей, а перед ними ещё пара сервисов, которые в памяти всё джойнят, фильтруют и ремапят. Welcome to 2018

Это уровень 1С - главное бабки заработать здесь и сейчас - в таких случаях пишут на хранимках и прочих костылях.

1. Они не DB agnostic. // Хотя нахрен не нужно в 95% случаев

Тут ходят слухи, что oracle запретят и скажут все переделывать на postgress. Боятся, но пилят дальше на oracle.

2. Их сложно тестировать и следить за их изменением

Это да. В частности за тем, что творится во временных таблицах. Год назад дебажил один отчёт, но пригорело так, что еще помню.

Душа олдфага разделяет желание пописать логику на теплом ламповом (plpgsql? pl-sql? не важно, они все теплые)

Ну я - то молодооой, я могу и на яве и на ноде, а мои коллеги смотрят на меня как на хипстора.

а мои коллеги смотрят на меня как на хипстора.

Как будто что то плохое.

Это уровень 1С - главное бабки заработать здесь и сейчас

Что такого плохого в 1С? Просто все говорят, а я никогда с 1с не работал (впрочем и не хочется сильно).

В принципе, ты в этом посте уже ответил на свой вопрос - хранимки не нужны тебе. Да и в принципе, в большинстве случаев не нужны.

oracle запретят и скажут все переделывать на postgress. Боятся, но пилят дальше на oracle.
Боятся, но пилят дальше

А вот это уже звоночек, такое не лечится. Пора что-то менять или валить.

А ещё лучше поменять и свалить - будет о чем рассказать эйчарам или будущему лиду

Мой предшественник так и поступил. Накатал им какой-то фигни на яве и уехал в тёплые края:)

Но у меня даже гироскутера нет. И то, что я пишу на ноде, там в зависимостях только amqplib.

Ничего плохого в 1С нет, так же как и в Microsoft Dynamics и т.д.

Разные подходы. Одним людям зашли, а другим нет - вот и бомбят некоторые...

Ничего особо плохого в 1С нету, апокалиптические картины рисуются благодаря невысокой культуре разработки в среднем. Лично мне не нравится отсутствие развития встроенного языка, а особенно языка запросов. Только «стандартную библиотеку» расширяют, вот и весь прогресс.

Я слышал только то, что там проблемы с закостыливанием, когда прошлые 1с-ники решают проблемы какими-то дикими способами и всё это приходится потом разгребать. Ну и работает это всё, как большой чёрный ящик.

многие еще угорают по хранимкам. Вы сталкивались с таким?

Уже почти десять лет сопровождаю ынтерпрайзную самоделку с бизнес-логикой в хранимках 10 Оракла.

Минусы: отсутствие версионирования, отсутствие тестирования, отсутствие дебага. Запросы, подзапросы и подзапросы в подзапросах. Хранимки вешаются, лочат таблицы, растёт очередь запросов от пользователей. Никто уже не понимает что происходит, перезагружаю сервис оракла. Или контейнер с ораклом. Временами под рутовым акком в контейнер врываются разрабы и от бедра отстреливают процессы oracle.

Плюсы: руководство пожимает плечами и покупает более мощный сервер.

Кто переделывал проект с одного на другое?

Если данных много, не советую. Лучше начни с нуля.

У нас львиная доля всего в Oracle DB зашита. Не особо удобно. Во-первых, толком ничего не понятно, и не знаешь, уже есть что-то необходимое тебе из реализованного. Во-вторых, обновлять это добро - то еще занятие. В-третьих, большая часть работы fullstack-java программера получается-таки на этот оракл. И да, переписывать это все дело планируем, но пока хз как.

А что насчёт производительности? У нас тут не хотят, потому что «эта ваша ждава тормозная, что может быть быстрее sql запросов?».

Это уровень 1С - главное бабки заработать здесь и сейчас - в таких случаях пишут на хранимках...

Моё мнение диаметрально противоположно.

Возможно где-то и существуют правильные 1С, но мне обычно попадаются такие, которые вообще никак не пользуются средствами СУБД. Покупать под такую 1Ску целый MSSQL Server - это как покупать Lexus только ради того, чтобы хранить в багажнике картошку.

Всё, что можно вынести на сторону СУБД - всё надо выносить. Если у Lexus есть подходящие кнопки - они должны работать. Триггеры, хранимки, периодические задания, логика целостности - всё, всё выносить из прикладного приложения в средства, предоставляемые СУБД. Иначе на кой ляд использовать таких монстров только как хранителей таблиц? В прикладном приложении оставлять только логику пользовательского интерфейса.

Мне так кажется. Так и делаю.

Бизнес логика

должна умереть. есть просто логика. бизнес в данном случае эвфемизм слову дебилы.
посему где её не храни, будет плохо.

Наш архитектор Оракла бросает иногда фразы «ближе к данным - быстрее», но поскольку там проверок овердофига (права, роли, разбор XML, выполнение запроса, формирование обратного XML и что там еще) - все не очень быстро, да. Но и JSF с DXHTML - то еще гуано тормознутое...

основной минус - рулить ими труднее.

вообще SQL базы это вещь в себе. «отличный» пример этого Oracle.
чем postgres точно лучше, так это меньшим кладеньем болта на окружающий мир, стандарты там и т.д.

1. про тестирование, изменение и версионирование - все вполне себе решаемые вопросы, было бы желание

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

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

А что насчёт производительности?

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

Ещё без выхода за пределы бд проще сохранять целостность. А так, хранимые процедуры нужны редко, но в этих редких случаях они незаменимы.

Тормознуть можно любую технологию. Это больше характеристика прямости рук разработчика.

Уже 10 лет участвую в разработке и поддержании такой системы. Данные и вся возможная логика в Firebird. Клиент максимально тонкий. Пока не заметил ни одного минуса такого подхода.

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

Можно в двух словах, что за система?

про тестирование, изменение и версионирование - все вполне себе решаемые вопросы, было бы желание

Как сделать адекватное тестирование/логирование, когда все через запрос+5 подзапросов?

как и во всех остальных случаях. тестирование в общем случае - это соответствие выходных данных комбинации входных и системы under test. да, мегакрасивых тестов не получится, но грамотный тестировщик с помощью любимого ЯП и чьей-то матери требования тестами покроет за адекватное время. сам таким страдал, прости г-ди. версионирование с учётом того, что ораклу можно сказать, какой версии у него теперь база - вообще не проблема. логи - ну они да. тут СУБД просветлению шибко препятствует, но мир в принципе не идеален

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

Расскажи нам как надо делать, чтобы не заработать бабок.

Бизнес логика в бд - зло, а какие-нить тяжелые расчеты лучше как раз в бд.

Если тебе не нужен ACID - тебе, скорее всего, не нужна РСУБД.

Если тебе нужен ACID, то как ты его добьёшься, вынеся ВСЁ в клиента? А если добьёшься - какова будет цена?

Что до middleware - то здесь, зачастую, действительно в первую очередь будет играть роль удобство сопровождения.

Неск вопросов, если вам не трудно.

На чем написан клиент? Что является конечным клиентом (веб-браузер/GUI/просто API)? Много ли клиентов, т.е. много ли запросов обслуживается? Под какой ОС работает Firebird? Слышал, что FB заброшен, не развивается и, якобы, имеет проблемы с надежностью (рушит базу) - как оно в реальности?

Минусы: отсутствие версионирования, отсутствие тестирования, отсутствие дебага.

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

Никто уже не понимает что происходит
Временами под рутовым акком в контейнер врываются разрабы и от бедра отстреливают процессы oracle.

вот и вся суть прохладной истории.

Сейчас в ынтерпрайзе всякая ява с нодой, но многие еще угорают по хранимкам.

ява с нодой отлично работают с хранимками.

плюсы хранимок: 1. легко разграничить доступ к данным

2. все лучше с latency, тк не гоняем данные база->бекенд->база->бекенд...

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

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

Если тебе нужен ACID, то как ты его добьёшься, вынеся ВСЁ в клиента

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

Какие плюсы

Автора хранимок сложнее уволить

минусы, подводные камни?

Масштабируемость снижается. Получится решение только для маленьких предприятий.

Сейчас в ынтерпрайзе всякая ява с нодой, но многие еще угорают по хранимкам...

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

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

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

... но если уж выбрана SQL-ная СУБДшка (да еще и Oracle), и задача, к примеру, чисто бухгалтерская, то тут хранимые процедуры - очень даже адекватный инструмент. Чем ближе ты к данным, тем более быстро и эффективно все будет работать. Ну и языковые возможности - вполне достаточные и более адекватные для такого класса задач. Тут же надо всё грамотно делать - транзакции, блокировки, ...

Так бизнес логика как раз таки и состоит из расчётов. Мыж расчётный центр.

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

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

Конечно не умеют. Ты хочешь, чтобы в этой дыре за эти деньги все всё умели? У нас даже архитектора бд нет. Даже просто человека, который бы за этой бд следит и бил по рукам.

Хранимку дёрнуть - не проблема. Всё упирается в качество костылей. Если там 1-2 подзапроса, то это терпимо. А когда из 5+ и у пользователей возникают вопросы типа «а почему оно так посчиталось» возникают проблемы.

Автора хранимок сложнее уволить

Аминь. Я бы даже сказал, его невозможно уволить.

Тут все упирается в удобство сопровождения всего этого добра. PL/SQL он таки не очень удобоваримый, а еще у нас любят архитектуру бд гнуть под средства разработки и в том месте, где любой маппер бы всё сделал приходится каждый раз городить запрос с 3-мя join'ами и подзапросом. И я боюсь думать, что настанет, когда придётся что-то менять в схеме бд.

На самом деле есть профи-программисты

Ну, где-то они точно есть. Но тут есть я - хипстер-костыльщик и пацаны, которые кодят на делфи+pl/sql с бородатых времён и еще видали фокспро под дос. Не знаю, насчёт профессионалы, не профессионалы, у них вроде работает, я туда смотреть боюсь.

Основной клиент на C++Builder, есть совсем тонкий под Linux, есть Web-сервер. Прямо сейчас 120 коннектов.
Firebird под Linux
Развивается, самая новая версия октябрь 2018. Никаких проблем с надежностью нет.

Не понимать. Бизнес логика это вроде как набор чиселок и ифов к ним. Если чиселки считаются самой базой - ок, главное чтобы потом не сама база определяла что с ними делать.

Пишу на делфи+pl/sql. Стараюсь по минимуму логики в клиенте. Ввод, вывод, проверка опечаток. Как я понимаю если данные не извлекаются SQL запросами, то такие данные и хранить надо не в SQL базе. А в ручную строить алгоритм оптимального извлечения данных из 10 таблиц, вместо того чтобы это делал оптимизатор, несколько неэффективно. Дополнительные приложения вместе с дополнительным сервером приложений нужны если модель данных не укладывается в реляционную.

Что значит все?

Как минимум - триггеры.

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

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

Не, ну так не бывает, разве что у каких-то учёных в вакууме. Это в любом случае не вся бизнес-логика. А что вы там считаете?