Бизнес-логика: база данных или прикладной уровень - PullRequest
38 голосов
/ 23 сентября 2008

Вековой вопрос. Где вы должны разместить свою бизнес-логику, в базе данных в виде хранимых процедур (или пакетов) или на уровне приложений / промежуточного уровня? И что более важно, почему?

Предположим, что независимость от базы данных не является целью.

Ответы [ 24 ]

4 голосов
/ 23 сентября 2008

Размещение кода на уровне приложения приведет к созданию приложения, независимого от БД.

Иногда из-за производительности лучше использовать хранимые процедуры.

Это (как обычно) зависит от требований приложения.

4 голосов
/ 23 сентября 2008

Единственное, что входит в базу данных - это данные.

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

Трудно поддерживать хороший контроль версий хранимых процедур. Код вне базы данных действительно прост в установке - когда вы думаете, что у вас неправильная версия, вы просто делаете SVN UP (возможно, установку) и ваше приложение возвращается в известное состояние. У вас есть переменные окружения, ссылки на каталоги и множество средств управления средой над приложением.

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

Код внутри базы данных, однако, намного сложнее в управлении. Нет подходящей среды - нет «PATH», ссылок на каталоги или других переменных среды - чтобы обеспечить какой-либо полезный контроль над тем, какое программное обеспечение используется; у вас есть постоянный глобальный набор прикладных программ, прикрепленный к базе данных и связанный с данными.

Триггеры еще хуже. Они оба - обслуживание и кошмар отладки. Я не вижу, какую проблему они решают; Похоже, они являются способом работы с плохо спроектированными приложениями, в которых кто-то не может правильно использовать доступные классы (или библиотеки функций).

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

[В примерах, которые я видел, старое приложение было плохо спроектировано; когда хранимые процедуры были написаны, приложение было перепроектировано. Я думаю, что изменение дизайна оказало большее влияние, чем изменение платформы.]

3 голосов
/ 21 декабря 2008

Ответ из моего опыта лежит где-то на спектре ценностей, обычно определяемых тем, где лежат навыки вашей организации.

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

И мало программистов, которые в достаточной степени понимают, что они не понимают в базах данных.

Отсюда и популярность неоптимальных понятий, таких как Active Records и LINQ (чтобы добавить некоторый очевидный уклон). Но они, вероятно, лучший ответ для таких организаций.

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

3 голосов
/ 23 сентября 2008

Бизнес-логика должна быть размещена на уровне приложений / промежуточного уровня в качестве первого выбора. Таким образом, его можно выразить в форме модели предметной области, поместить в систему контроля версий, разделить или объединить со связанным кодом (рефакторинг) и т. Д. Это также дает вам некоторую независимость от поставщика базы данных.

Объектно-ориентированные языки также намного более выразительны, чем хранимые процедуры, что позволяет вам лучше и проще описывать в коде, что должно происходить.

Единственные веские причины для размещения кода в хранимых процедурах: если это приводит к значительному и необходимому выигрышу в производительности или если один и тот же бизнес-код должен выполняться несколькими платформами (Java, C #, PHP). Даже при использовании нескольких платформ существуют альтернативы, такие как веб-службы, которые могут лучше подходить для совместного использования функций.

2 голосов
/ 21 декабря 2008

Имхо. Существует две противоречивые проблемы с выбором бизнес-логики в приложении на основе реляционной базы данных:

  • ремонтопригодность
  • надежность

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

Re. надежность: когда существует значительный риск несоответствия, бизнес-логика относится к уровню базы данных. Реляционные базы данных могут быть разработаны для проверки ограничений на данные, например, недопустимость значений NULL в определенных столбцах и т. д. Когда в проекте приложения возникает сценарий, когда некоторые данные должны находиться в определенном состоянии, которое слишком сложно выразить с помощью этих простых ограничений, может иметь смысл использовать триггер или что-то подобное на уровне базы данных.

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

В нашем приложении большая часть бизнес-логики содержится на уровне модели приложения, например Счет-фактура знает, как инициализировать себя из данного заказа на продажу. Когда куча разных вещей изменяется последовательно для такого сложного набора изменений, как этот, мы сворачиваем их в транзакцию для обеспечения согласованности, вместо того, чтобы выбрать хранимую процедуру. Подсчет итогов и т. Д. Выполняется методами на уровне модели. Но когда нам нужно что-то денормализовать для повышения производительности или вставить данные в таблицу «изменений», используемую всеми клиентами, чтобы выяснить, какие объекты им нужно истечь в их кэше сеансов, мы используем триггеры / функции на уровне базы данных, чтобы вставить новую строку и отправьте уведомление (Postgres прослушать / уведомить материал) из этого триггера.

После того, как наше приложение использовалось в течение года и использовалось сотнями клиентов каждый день, единственное, что я мог бы изменить, если бы мы начали с нуля, - это разработать нашу систему для создания функций базы данных (или хранимых процедур). (однако вы хотите позвонить им) с учетом версий и обновлений для них с самого начала.

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


Конечно, все меняется, когда вы выходите за рамки RDBMS в системы хранения кортежей, такие как Amazon SimpleDB и Google BigTable. Но это другая история:)

2 голосов
/ 23 сентября 2008

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

Я хочу сказать, что бизнес-логику нужно поместить в уровень приложения, но есть исключения (в основном из-за соображений производительности)

2 голосов
/ 23 сентября 2008

бизнес-приложений «Слои»:

1. Пользовательский интерфейс

Это реализует представление бизнес-пользователя о задании h (is / er). Используются термины, с которыми знаком пользователь.

2. Обработка

Здесь происходят вычисления и манипулирование данными. Здесь реализована любая бизнес-логика, которая включает изменение данных.

3. База данных

Это могут быть: нормализованная последовательная база данных (стандартные СУБД на основе SQL); OO-база данных, хранящая объекты, обертывающие бизнес-данные; и т.д.

Что идет Куда

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

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

2 голосов
/ 23 сентября 2008

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

1 голос
/ 23 сентября 2008

Я помню, как читал где-то статью, в которой говорилось, что на каком-то уровне все может быть частью бизнес-логики, и поэтому вопрос бессмысленен.

Я думаю, что приведенный пример был отображением счета на экране. Решение пометить просроченную красным цветом является деловым решением ...

1 голос
/ 23 сентября 2008

Мы храним много бизнес-логики в хранимых процедурах - она ​​не идеальна, но часто это хороший баланс между производительностью и надежностью.

И мы знаем, где это, без необходимости искать через акры решений и кодовой базы!

...