Добавление бизнес-логики непосредственно в SQL-запросы может выглядеть как удобный выход из положения, но в долгосрочной перспективе такой подход чреват множеством проблем.
Вот 5 основных причин, почему это не рекомендуется:
1️⃣ Сложность поддержки и отладки
SQL-запросы, содержащие сложную логику, становятся трудно читаемыми и практически невозможно разобраться, что где работает неправильно. Чем больше там логики, тем сложнее её тестировать и исправлять ошибки.
2️⃣ Нет повторного использования кода
SQL, как правило, плохо подходит для повторного использования кода. Если логику нужно применить или изменить в другом месте, её придется копировать, что создаёт избыточность и увеличивает количество «точек отказа».
3️⃣ Перенос сложности в неподходящий слой
SQL-запросы должны использоваться для манипуляции с данными, тогда как бизнес-логика должна быть на уровне приложения, где существуют инструменты для её структурирования и управления.
4️⃣ Сложности масштабирования
Когда бизнес-логика находится внутри SQL, нагрузка на базу данных значительно возрастает. В результате сложно масштабировать приложение горизонтально, так как появляются узкие места в производительности базы данных.
5️⃣ Трудности работы с несколькими хранилищами данных
Если ваша система использует не одну базу данных (например, SQL + NoSQL), размещение логики в SQL усложняет интеграцию и синхронизацию данных между разными система.
Когда можно писать бизнес-логику в SQL?
Есть ситуации, когда это допустимо. Например, если система очень небольшая, а логика тесно связана с работой с данными, такие как отчёты или рекомендации по агрегированным данным. В этом случае можно встроить часть логики в запрос для упрощения. Однако, будьте готовы к ограниченным возможностям масштабирования такого подхода.
Пишите код грамотно и помните: бизнес-логика должна быть там, где ей место — в приложении. 😉
0
Комментарии (7)
популярные
новые
старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Что такое бизнес логика в SQL запросах? Это какой-то сложный Select, Update, ALTER? Это DDL или DML? Или процедура или функция? Я на работал Java программистом и поэтому не понимаю что это может означать.
Если речь о PL/SQL то могу добавить что одним из факторов сложности содержания бизнес логики в БД это не достаточная компетентность Java специалистов этой области. Сам я сейчас Data Engineer и видел много PL/SQL пакетов с десятками процедурами и функциями на 5000+ строк кода с бизнес логикой. Я не специалист в области и сам не силен в PL/SQL, но могу сказать что некоторую логику легче, лучше и правильнее писать в самой СУБД. Просто есть БЛ нужная для backend разработчика, а есть БЛ которая нужна в рамках самой БД и специалистов которые работают с ним. Аналитики ежедневно запускают процедуры и загружают себе JSON, XML файлы в BI, DI инструменты и для этого не нужен никакой Java, Python или другой backend язык. А в банках работают PL/SQL developer-ы которые десятки лет писали эту самую "бизнес логику" в СУБД и особо не встречались с backend - ом. Сейчас говорят что эти самые "Python, Java" коды можно исполнять в самой БД. Поэтому мне кажется что есть и обратная сторона которая говорит: "Почему писать бизнес-логику в backend — плохая идея и лучше писать ее в СУБД".
По итогу могу сказать что писать БЛ в СУБД не стоит:
1) Если в команде/проекте нет Senior SQL, PL/SQL developer - а
2) Если вы не сильны в PL/SQL.
Бизнес логика это набор правил по которому работает твоё приложение.
Предположим у тебя есть место в системе которое упаковывает башмаки, при том для синих башмаков упаковка одна, для красных другая, а для всех остальных третья.
Можно было бы конечно сделать три селекта в базу, и результат каждого скормить отдельному обработчику, а можно сделать findAll и решить в коде какой башмак в какую коробку пойдёт. При том если мне понадобится добавить новые коробки я не буду писать новые селекты в базу. Пример конечно высосан из пальца но показывает как можно сэкономить на запросах в базу и не грузить I/O выше необходимого.
Ну или другой пример, если в твоём репорте присутствует человек конкретного типа, то для этого человека надо отправить электронное письмо с поздравлением, что он молодец. И основная мякотка здесь даже не в том что я хз как из базы отправлять электронные письма, и даже не в том, что не все базы это могут уметь, а в том что сам по себе отчёт собирается из двух десятков разных таблиц в разных же местах приложения и типов репортов у тебя как у дурака фантиков, и для каждого типа простыня с описанием своих кастомных правил, в том числе один и тот же человек может играть разные роли в разных отчётах :) Например в отчёте по успеваемости он может быть "работник месяца", а в отчёте по атмосфере в коллективе "токсичный му*ак" и в обоих случаях поведение должно быть разным.
Можно ли условно это все запихать на уровень базы? Ну... достаточно много можно, но так ты размазываешь логику по нескольким местам, а чем больше мест надо в случае чего править или просто вычитывать, тем больше места для ошибки.
Было бы круто приложить несколько примеров "что такое хорошо" и "что такое плохо". Заодно пояснить что такое бизнес логика :)
А то сферический конь в вакууме не очень нагляден.
Вот например пятый пункт, каким образом хранилище и квери влияют на интеграцию с базой? Ну т.е. у меня есть условный репозиторий с кучей кастомных кверей на JPQL, но это все еще достаточно высокий уровень абстракции чтобы сменить какой ни будь постгрес на мускуль потом на H2 потом еще на что ни будь и не особо почувствовать разницу.
Если говорить о четвёртом пункте, тут мне кажется вопрос не в нагрузке на БД, а в ее архитектуре и корректности написания запросов. Ну хотя бы из базового - делать выборки по индексам, или напротив не навешивать их слишком много на таблицы в которые активно идёт запись. Я конечно не мерял, но какой ни будь findAll() может оказаться тяжеловеснее findByMyQustomQuery() который вернет тебе сильно меньше результатов.
Третий пункт... что ж такое эта бизнес логика все таки?) Мне казалось это тоже инструмент манипуляции с данными :) Ну там этим показываем, этим не показываем, тут рыбу заворачиваем....
Второй пункт... я конечно могу ошибаться но бизнес логика в целом штука узкопрофильная и доменоспецифичная, даже если ты предоставляешь один и тот же сервис нескольким клиентам, вполне вероятно они хотят чтобы он работал несколько по своему. Например формат данных для трекинга посылок у разных перевозчиков отличается. Ну так... в порядке бреда накинул :)
По первому пункту в целом согласен, трёхэтажные монстры из хранимок и триггеров не самое приятное чтиво.
Я бы еще добавил что далеко не всегда доступ в эту самую базу вообще имеется. Ну т.е. у тебя как разработчика конечно же есть средства работы с базой из кода, но прямого доступа в базу вполне может и не быть, а это накладывает некоторые ограничения. Например необходимость добрасывать те же хранимки через миграции, да и с отладкой что делать не ясно будет... и вот это уже борщ.
Зачем? :) я не вполне твоя целевая аудитория, а вот нубы которые это прочтут или просто ничего не поймут или могут запутаться, потому на мой взгляд нужно писать максимально однозначно и с кучей наглядных примеров, объясняя почему именно, тот или иной пример плох или хорош.