Содержание
Да потому что так практичнее и… правильнее
Современные приложения все чаще используют базы данных исключительно как «хранилище», а не как движок для бизнес-логики. Почему?
Потому что SQL, несмотря на свое превосходство в работе с данными, неудобен, ограничен и рискован в роли полноценного языка программирования.
Логика не по адресу
Как отмечает Эвальд Бенс, фуллстек разработчик и авторов популярного блога об IT, он предпочитает держать как можно больше логики в приложении, а не в SQL-хранилищах, представлениях и процедурах:
Я отношусь к базе как к тупому хранилищу данных. Вся логика — в коде. SQL просто не предназначен для сложных сценариев.Эвальд Бенсразработчик
И дело не в том, что SQL чего-то «не умеет». Умеет — особенно с расширениями вроде PL/pgSQL или Oracle PL/SQL.
Но выразительность этих языков — далека от Python, TypeScript, Rust или C#, особенно когда речь идет о бизнес-логике, объектной модели или сложных расчетах.
Зачем выносить логику из базы?
1. SQL невыразителен
Для манипуляций с табличками и JOIN — он король. Но как только начинается рекурсия, классы, вложенные состояния или обработка ошибок — SQL превращается в монстра с BEGIN, IF, LOOP, EXCEPTION, RAISE, CURSOR, FETCH, WHILE и т.д…
2. Развертывание — боль
Обновить приложение можно за минуту, откатить — за две. А вот миграции на проде — это:
- повышенные права доступа;
- согласование с DBA;
- боязнь сломать что-то «наживую»;
- ручной откат схем.
3. Лочит на вендора
Логика, написанная на PL/SQL — это билет в один конец к Oracle. Переезд на PostgreSQL или SQL Server становится в 5 раз сложнее.
4. Меньше инструментов
Вокруг SQL есть утилиты, но полноценной среды с юнит-тестами, статическим анализом, форматтерами, профайлерами, линтерами и отладчиками — почти нет.
А что с производительностью?
Да, есть нюанс: иногда лучше обработать данные прямо в базе, чтобы не гонять десятки тысяч строк по сети. Это особенно актуально, если не хочется получить классическую проблему N+1-запросов.
Но даже в этом случае большинство специалистов советует сначала делать «просто и понятно», а не «оптимально заранее». До тех пор, пока не уперлись в реальные метрики, выносить логику в базу — преждевременная оптимизация.
Что делать?
Подход «база — хранилище, логика — в коде» стал де-факто стандартом во многих командах. Но это не догма:
- Для отчетности или простых ETL сценариев логика в SQL может быть уместной.
- Для монолитных решений без CI/CD и DevOps — процедурный SQL вполне оправдан.
- Но в современной разработке с частыми релизами, микросервисами и отказоустойчивостью бизнес-логика в приложении — просто удобнее и безопаснее.