Важное дополнение по итогам анализа комментариев и минусов к публикации.
С моей личной точки зрения - я за то, что бы всё , что не касается СУБД , было вынесено из СУБД: бизнес-функции, агрегация, сортировка, ограничения и проверки корректности данных, ссылочная целостность - пусть рассчитывается и обрабатывается на уровне backend. Это позволит загрузить очень интересной работой современное поколение разработчиков , задействовать новые возможности фреймворков и ORM и позволит специалистам DBA сконцентрироваться на своей прямой работе - связанной с сопровождением и оптимизацией производительности СУБД. Если эта мысль не была понятна, прошу прощения. Теперь, наверное точки над i - расставлены.
Вот интересно , а проводились ли сравнительные испытания производительности информационной системы - до и после переноса бизнес логики с уровня СУБД на уровень backend ?
Теоретически наверное можно сделать синтетические тесты . Очень было бы интересно, сравнить производительность. Разница однозначно должна быть . Но пока не встречал подобных работ. Наверное потому, что тема чисто академическая, а с НИОКР в области СУБД и информационных технологий вообще дело не очень.
Но ещё более интересен другой вопрос - а проводились ли расчёты стоимости владения и сопровождения информационных систем с разными уровнями хранения бизнес логики.
Например, в самом общем, простейшем случае:
Бизнес логика в СУБД: 1 сервер СУБД + 1 сервер middle level
Бизнес логика в backend: 1 сервер СУБД + 1 application сервер.
Меня терзают смутные сомнения:
вариант 2-не масштабируем. Т.е. увеличение ресурсов сервера приложений не даст прироста производительности системы в целом(проверено на практике). Вопросы масштабируемости информационной системы , вообще тема сложная, мне пока не повезло участвовать в практических реализациях.
вариант 2- будет существенно дороже - вот это самое интересное .
в случае существенного роста объёмов и нагрузки у варианта 2 будут проблемы (это утверждение кстати, реально подтверждается практикой - наращиваются ресурсы серверов приложений , сервер СУБД не перегружен)- ситуация информационная система тормозит , но нагрузка и производительность СУБД средние - стандартная .
Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам. Масштабируемость можно оценить через отношение прироста производительности системы к приросту используемых ресурсов. Чем ближе это отношение к единице, тем лучше. Также под масштабируемостью понимается возможность наращивания дополнительных ресурсов без структурных изменений центрального узла системы.
Это в теории , а в реальной жизни - проектирование информационных систем , начинается не с планирования ресурсов и исполнителей под конкретно поставленную задачу и бюджет , а наоборот- набор, состав и уровень знаний и умений конкретной команды исполнителей - определяют способ решения задачи и архитектуру решения. Реальный случай из практики - разработчики использовали фреймворк , который использует эксклюзивные блокировки, не потому , что была какая то причина или эффективность решения , просто они привыкли работать с этим фреймворком. Результат закономерен и ожидаем - после передачи в промышленную эксплуатацию каждую неделю - аварийные ситуации. После рефакторинга - все работает штатно . Вопрос - что мешало сразу сделать по человечески ? Ничего , кроме привычки и косности мышления - сработало раньше , наверное заработает и сейчас .
Или другими словами - решение о выборе архитектурного решения "бизнес логика в приложении" принимается не потому, что это решение эффективнее и ниже по стоимости сопровождения , а просто - нет уже исполнителей способных реализовать бизнес-логику на уровне СУБД. Все используют фреймворки и ORM. И никто в принципе не будет считать и анализировать - решения основываются исключительно на субъективном мнении конкретных архитекторов и руководителей команды разработки продукта.
А если нет конкретных результатов исследований о более низкой стоимости сопровождения решения с размещением бизнес логики на уровне приложения - какой смысл в разговорах не подкрепленных конкретными цифрами о более удобном и гибком подходе ? Это же просто слова и личное мнение за которым не стоят данные объективных и независимых тестов.
В общем , как говорится - тема ждет своего исследователя . Жаль доценты кафедр прикладной математики или информатики занимаются не научной работой, а озвучиванием документации.
И очень жаль, что когда нам читали теорию систем , я был сильно увлечен C++ и не уделял должного внимания фундаментальным дисциплинам . Теперь приходится вспоминать и наверстывать.
P.S.Вряд ли конечно ситуция изменится , нет причин меняться - бюджеты никто не считает , современному поколению разрабов и манагеров ничего не объяснить- они в тренде "фигак, фигак и в продакшн" , но с научной точки зрения наверное тема интересная , может быть кто и возьмётся . Было бы интересно ознакомится с результатами.
