Должны ли применяться бизнес-правила как на уровне приложения, так и на уровне базы данных, или только в одном из двух?

Question

Я применяю бизнес-правила как на уровне приложений (модели), так и на уровне базы данных (хранимые процедуры, которые вызывают ошибки).

Я дублировал свои проверки в обоих местах по нескольким причинам:

1. Если условия изменяются между когда они проверены в код приложения и когда они проверил в базе данных, проверка бизнес-правил в базе данных спасет день. База данных также позволяет мне заблокировать различные записи в более простой форме, чем в мой код приложения, так кажется естественно сделать это здесь.
2. Если у нас есть сделать некоторые данные партии вставки / обновления в базу данных напрямую, если я маршрутизирую все эти операции через мой хранимые процедуры / функции, которые делают бизнес-правило проверки, у меня нет шансов ввод плохих данных, даже если мне не хватает средств защиты, которые я получал бы, если бы делал однократный ввод через приложение.
3. В то время как соблюдение этих вещей ТОЛЬКО в база данных будет иметь тот же эффект на реальных данных, кажется неправильно просто бросать данные на базы данных, прежде чем сделать хороший усилия, чтобы подтвердить, что это соответствует к ограничениям и бизнес-правилам.

Какой правильный баланс?

Answer 1

Для обеспечения целостности данных необходимо применять на уровне данных.Это ваша последняя линия защиты, и это работа с БД, чтобы помочь обеспечить мировоззрение данных.

Тем не менее, выбрасывать ненужные данные в БД для проверки - грубая техника.Обычно ошибки предназначены для чтения человеком, а не для чтения машиной, поэтому неэффективно, чтобы программа обрабатывала ошибку из БД и делала из нее головы или хвосты.

Хранимые процедуры - это другое дело.В свое время хранимые процедуры были способом обработки бизнес-правил на уровнях данных и т. Д.

Но сегодня, с современными средами серверов приложений, они стали, в общем, лучшим местом для этогологика.Они предлагают несколько способов доступа и предоставления данных (веб, веб-сервисы, удаленные протоколы, API и т. Д.).Кроме того, если ваши правила перегружены процессором (возможно, большинство из них не так), то масштабировать серверы приложений легче, чем серверы БД.

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

А по серверу приложений я непросто говоря на Java, но .NET и даже PHP и т. д.

Answer 2

Если правило должно применяться всегда, независимо от того, откуда поступили данные или как они были обновлены, база данных находится там, где она должна быть. Помните, что на базы данных влияют прямые запросы на внесение изменений, которые влияют на многие записи, или на действия, которые приложение обычно не делает. Это такие вещи, как исправление группы записей, когда клиент выкуплен другим клиентом, и они хотят изменить все исторические данные, применение новых налоговых ставок к заказам, которые еще не обработаны, исправление некоторых неверных входных данных. На них также иногда влияют другие приложения, которые не используют ваш уровень данных. На них также может влиять импорт, выполняемый через программы ETL, которые также не могут использовать ваш уровень данных. Поэтому, если правило должно соблюдаться во всех случаях, оно должно быть в базе данных.

Если правило относится только к особым случаям, касающимся того, как работает эта конкретная страница ввода, то оно должно быть в приложении. Таким образом, если у менеджера по продажам есть только определенные вещи, которые он может сделать из своего пользовательского интерфейса, эти вещи могут быть указаны в приложении.

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

Answer 3

Ваша бизнес-логика может находиться в любом месте, но не должна быть в обоих.Логика НЕ ​​должна дублироваться, потому что легко допустить ошибку, пытаясь синхронизировать оба.Если вы поместите его в модель, вы захотите, чтобы весь доступ к данным проходил через ваши модели, включая пакетные обновления.

Возможны компромиссы при помещении его в базу данных по сравнению с моделями приложений (вот некоторые из моих соображений):

• Базы данных могут быть сложнее поддерживать иобновление, чем приложения
• Распределить нагрузку легче, если она находится на уровне приложения
• Несколько разрозненных БД могут потребовать разделения бизнес-правил (что может быть невозможным)