Имхо. Существует две противоречивые проблемы с выбором бизнес-логики в приложении на основе реляционной базы данных:
- ремонтопригодность
- надежность
Re. Сопровождаемость: для обеспечения эффективной будущей разработки бизнес-логика относится к той части вашего приложения, которую проще всего отлаживать и контролировать версии.
Re. надежность: когда существует значительный риск несоответствия, бизнес-логика относится к уровню базы данных. Реляционные базы данных могут быть разработаны для проверки ограничений на данные, например, недопустимость значений NULL в определенных столбцах и т. д. Когда в проекте приложения возникает сценарий, когда некоторые данные должны находиться в определенном состоянии, которое слишком сложно выразить с помощью этих простых ограничений, может иметь смысл использовать триггер или что-то подобное на уровне базы данных.
Триггеры - это боль, чтобы быть в курсе, особенно когда ваше приложение должно работать на клиентских системах, к которым у вас даже нет доступа. Но это не значит, что их невозможно отследить или обновить. Аргументы С. Лотта в его ответе о том, что это боль и неприятности, полностью действительны, я повторю это и тоже был там. Но если вы помните об этих ограничениях, когда впервые проектируете слой данных, и воздерживаетесь от использования триггеров и функций для чего-либо, кроме абсолютных потребностей, которыми можно управлять.
В нашем приложении большая часть бизнес-логики содержится на уровне модели приложения, например Счет-фактура знает, как инициализировать себя из данного заказа на продажу. Когда куча разных вещей изменяется последовательно для такого сложного набора изменений, как этот, мы сворачиваем их в транзакцию для обеспечения согласованности, вместо того, чтобы выбрать хранимую процедуру. Подсчет итогов и т. Д. Выполняется методами на уровне модели. Но когда нам нужно что-то денормализовать для повышения производительности или вставить данные в таблицу «изменений», используемую всеми клиентами, чтобы выяснить, какие объекты им нужно истечь в их кэше сеансов, мы используем триггеры / функции на уровне базы данных, чтобы вставить новую строку и отправьте уведомление (Postgres прослушать / уведомить материал) из этого триггера.
После того, как наше приложение использовалось в течение года и использовалось сотнями клиентов каждый день, единственное, что я мог бы изменить, если бы мы начали с нуля, - это разработать нашу систему для создания функций базы данных (или хранимых процедур). (однако вы хотите позвонить им) с учетом версий и обновлений для них с самого начала.
К счастью, у нас есть какая-то система для отслеживания версий схемы, поэтому мы создали что-то еще, чтобы позаботиться о замене функций базы данных. Хотя это сэкономило бы нам некоторое время, если бы мы рассмотрели необходимость заменить их с самого начала.
Конечно, все меняется, когда вы выходите за рамки RDBMS в системы хранения кортежей, такие как Amazon SimpleDB и Google BigTable. Но это другая история:)