Есть очень интересная статья Dude, where's my business logic? и ее перевод на русский — Где наша бизнес-логика, сынок?. В статье рассказывается об эволюции архитектуры приложений от однозвенного до n-звенного. В контексте этой темы поднимается вопрос о том, что такое бизнес-логика и в каком слое она должна находиться. Автор рассказывает, что когда появилась двухзвенная архитектура, то перемещение логики работы с данными в хранимые процедуры способствовало повышению производительности приложений. Однако, вместе с кодом для работы с данными часто в хранимки может попасть и бизнес-логика, а это очень плохо.

Базе данных не должно быть дела до того, что такое бизнес-сущность, она должна заботиться только об элементах, используемых для хранения этой бизнес-сущности. У базы данных не должно быть возможности разобраться, какие таблицы должны хранить эту сущность, и она должна работать с таблицами не обращая внимания на бизнес-объект. Задача базы данных – хранить строки в таблицах, которые описывают объект. Кроме базовых ограничений вроде каскадной целостности, типов данных, индексов и пустых значений, база данных не должна иметь функционального знания о том, что же из себя представляет объект в бизнес слое.

Хранимые процедуры, если они есть, должны оперировать только одной таблицей; исключение – это процедуры запрашивающие выборку из нескольких таблиц для выдачи данных. В этом случае, хранимые процедуры работают как представления (view). Представления и хранимые процедуры должны использоваться для консолидации значений, но исключительно для более быстрой и эффективной работы с данными в бизнес слое.

Автор отмечает следующие недостатки присутствия логики в хранимых процедурах:

• Трудности при переходе на другие СУБД.
• Сложность модификации и отладки из-за того, что логика распределена по нескольким слоям.
• Вместе с логикой хранения данных в хранимые процедуры может подмешаться бизнес-логика. Это происходит потому, что проектировщику может показаться «проще» и «логичнее» сделать именно так.

Однако, есть и исключения:

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