Задать вопрос
alexeyshkolnik
@alexeyshkolnik

Почему нельзя/можно писать бизнес-логику в sql?

Вопрос по архитектуре: очень часто слышу, что нельзя БЛ писать в SQL. Хочу понять почему. Аргумент о том, что будем менять БД не подходит, БД менять ближайшие 10 лет не собираемся.
Вижу минус: в БЛ опираемся на сущности БД, но это не страшно или нет?
Плюсы: очень просто вносить изменения - затрагивается только один слой - база данных, и минимальные или вообще никаких изменений на фронте.
  • Вопрос задан
  • 1102 просмотра
Подписаться 3 Средний 1 комментарий
Пригласить эксперта
Ответы на вопрос 6
mayton2019
@mayton2019
Bigdata Engineer
Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
бизнес логики из 20-го века.

В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
даже заменяемым на другие типы баз.

Но не все так плохо.

Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
есть какая-то минимальная логика, например при аутентификации или при проверке
валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
Потому что агрегировать в приложении все - глупо. Это лишний трафик.

И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.
Ответ написан
rozhnev
@rozhnev
Fullstack programmer, DBA, медленно, дорого
У каждого из подходов есть свои преимущества и недостатки.
К недостаткам можно отнести:
  • Сложность отладки и тестирования
  • Затрудненная версионность
  • Зависимость от конкретной СУБД
  • Ограниченные возможности языка
  • Сложности с масштабированием
  • Возможные side-эффекты

К преимуществам:
  • Уменьшение трафика
  • Цетрализованная логика
  • Безопасность данных
Ответ написан
ThunderCat
@ThunderCat
{PHP, MySql, HTML, JS, CSS} developer
Когда в руках молоток, все вокруг становится похожим на гвоздь... Если вы хорошо разбираетесь в языках запросов, это не говорит о том что это распространенный навык.
Самый простой аргумент - посмотрите на рынок, много ли движков, построенных на бд/sql?
Много ли специалистов по бд вообще на рынке труда?
Кто из них разрабатывал логику на стороне бд?
Кроме того, слои яп-бд можно разнести на разные инстансы, что сильно распределит нагрузку, а бд сама по себе умеет в пожрать ресурсы...

Можно долго перечислять плюсы и минусы. Смысл в том что если вы будете разрабатывать это сами или для себя и вы уверены в собственной способности построить всю логику на одной технологии- флаг в руки, это будет оригинальным решением, вполне возможно даже что найдутся ценители.
Если же проект для заказчика, и в разработке будут участвовать 2+ людей, то тут то вы хапнете проблем большой ложкой. Найти спецов которые прям пишут логику на скуеле, чтобы они стоили приемлемых денег, завтра не ушли в другой проект так как тут надо делать кучу непрофильных дел: как-то делить задачи, вести версионирование, не пересекаться с другими задачами функционалом... проще пойти в нормальную контору, где от дбшника требуют только структуру, пару триггеров и он там один отвечает за бд, так как больше не нужно и ни с кем из коллег не надо 10 раз утверждать изменения в структуре/процедурах/етц. Короче это не специфично и мало кто захочет все это изучать с новой стороны. Про поддержку такого чуда я вообще молчу.

Это еще не учитывая того что в проекте все равно понадобится пара программистов на каком-то ЯП, для формирования отображения и какой-то прослойки между пользователем и бд, которые должны будут разобраться с этим зоопарком наоборот.
Ответ написан
ipatiev
@ipatiev
Потомок старинного рода Ипатьевых-Колотитьевых
Вопрос из серии "У меня есть своя дурацкая точка зрения, которую я ни сформулировать толком не могу, ни подкрепить никакими доводами. Давайте, переубеждайте меня!"

Вы просто не поняли статью, которую читали.
Там говорятся банальные вещи о том, что бизнес-логика не должна завязываться на конкретное хранилище. То есть там было сказано ровно противоположное тому что у вас. Не "БЛ нельзя писать в SQL", а наоборот - в бизнес логике не должно быть SQL. Просто потому что чистый код и разделение ответственности. Сейчас у вас SQL, завтра эластик, а послезавтра микросервис по НТТР. Да, БД, которыми пользуются все три, "осталась та же самая". Способ ходить в неё поменялся.
Плюс тупо упрощается код, с ним проще работать. БЛ отдельно, БД - отдельно. Именно об этом и говорится в статье.

Но могу вас утешить. Всё это говорится про более-менее сложные приложения.
Говнокодить свою домашнюю страничку про котиков, или интернет магазин по продаже мёда с пасеки любимого дядюшки вы можете как угодно, хоть в SQL, хоть в Brainfuck-e.
Ответ написан
php666
@php666
PHP-макака
Аргумент о том, что будем менять БД не подходит, БД менять ближайшие 10 лет не собираемся
этот аргумент кочует лет 20, причем не только в отношении БД, а вообще всего.

В PHP, например, абстракция PDO - почти такой же надуманный предлог, мол, а если база поменяется?

Вот когда поменяется база, наймут новых разработчиков и они будут заново пилить и переписывать. Потому, что ПО ФАКТУ со сменой базы меняется всё - начиная с формата получения данных в клиентском коде и заканчивая теми участками, где используются какие-то фитчи конкретной СУБД, как, например, в MySql ONLY_FULL_GROUP_BY без которого SQL на другой базе попросту не сработает или функции, специфичные для бывшей/текущей БД.

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

Между тем, адепты не писать логику в БД почему-то тихо "игнорируют" такие вещи, как внешние ключи и такие вещи как ON DELETE CASCADE с удовольствием используют, а не пишут цикл перебора с методом delete для каждой из связанных сущностей.
Ответ написан
@FernandoErrNando
Вам указывали недостатки, но, почему-то для вас "Всё минусы какие-то мутные (кроме зависимости от конкретной БД)".
Давайте попробуем посмотреть повнимательнее:
1. Сложность отладки и тестирования - в то время, когда я работал с такими приложениями была проблема с тем, что средства отладки были слишком неразвиты, зачастую приходилось пользоваться dbms_output и все, чтобы отладить процедуру. думаю, нормыльные даббагеры потом появились, но я уже к тому времени ушел. Как сейчас обстоит с этим в РСУБД?
2. Затрудненная версионность - а разве не так? На больших проектах со множеством разработчиков это ещё как будет стрелять. Просто посмотрите как мучаются люди с данной проблемой https://habr.com/ru/articles/330662/, тогда как те, кто использует БЛ вне базы просто пользуются гитом
3. Зависимость от конкретной СУБД. Вы уверены, что БД у вас всегда будет подходить под требования бизнеса на 10 лет? Что, если за 10 лет появятся задачи, которые лучше решать другими инструментами? А если появятся задачи которые можно решить только сторонними инструментами?
4. "Ограниченные возможности языка" - можно ли решить все проблемы с помощь SQL/PL-SQL?
5. Сложности с масштабированием/оптимизацией - здесь тоже намного сложнее все. Кэширование вы тоже на СУБД будете возлагать? Что будет, когда у вас серверов БД будет больше 1?
6. Что насчет интеграций? Что будет, если вам надо будет ходить по АПИ в третьесторонний сервис? вы это тоже заложите в логику в БД?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы