Бизнес-логика в базе данных по сравнению с кодом?

Ответ 1

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

Базы данных отлично подходят для CRUD, но если они раздуты с логикой:

• Это становится запутанным, где логика,
• Обычно базы данных представляют собой силос и не масштабируются горизонтально почти так же, как и серверы приложений.
• t_sql/PLsql трудно читать и процедурно в природе
• Вы теряете все преимущества OOAD.

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

Ваше использование термина "бизнес-логика" довольно расплывчато.

Он может быть истолкован как означающий включение принудительного ограничения на данные (так называемые "бизнес-правила" ). Выполнение этих требований однозначно относится к периоду dbms.

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

Ответ 5

Мы делаем много обработки в ядре DB, где это необходимо. Там много операций, которые вы не хотели бы отбрасывать большие наборы данных в уровень приложения, чтобы анализировать. Это также более простое развертывание для нас - одно очко или обновление приложений во всех точках установки. Но многое зависит от вашего приложения и от того, что он делает; здесь нет ни одного хорошего ответа.

Ответ 6

В нескольких случаях я поставил "логику" в sprocs, потому что CRUD может происходить в более чем одном месте. По логике я бы сказал, что это не бизнес-логика, а логика целостности. Это может быть одно и то же: какая-то очистка может потребоваться, если что-то удаляется или обновляется определенным образом, и если это удаление или обновление может произойти из более чем одного инструмента с разными кодовыми базами, имеет смысл вставить его в proc, все используемые.

Кроме того, иногда "линия бизнес-логики" довольно размыта. Возьмите отчеты, например, они могут полагаться на хранимые процедуры или представления, которые инкапсулируют "умные" сведения о том, что означает схема для бизнеса. Как часто вы видели заявления CASE и т.п., Которые "делают вещи" на основе значений столбцов или других критериев? Может быть истолковано как бизнес-логика, и, тем не менее, он, вероятно, принадлежит к БД, где его можно оптимизировать и т.д.

Ответ 7

Я бы сказал, что если "бизнес-логика" означает поток приложений, пользовательский контроль, синхронизированные операции и, как правило, "делающий бизнес", то он должен быть на прикладном уровне. Но если это означает, что, независимо от того, как вы копаетесь в данных, это всегда имеет смысл и является разумным, несамостоятельным целым, тогда проверки для обеспечения соблюдения этих правил входят в БД, абсолютно, без вопросов. Всегда есть много способов подталкивать данные в БД и манипулировать им, когда они есть. Не у всех этих способов есть "бизнес-логика", встроенная в них. Вы найдете SQL-сессию в БД через окно DOS при вызове поддержки в 3 часа ночи, очень либерально в том, что он позволяет, например! Если логика не находится в БД, чтобы убедиться, что все изменения данных имеют смысл, вы можете сделать ставку на то, что данные будут очень сильно искажены с течением времени. И поскольку система является настолько же ценной, как и данные, которые она хранит, это значительно снижает доходность инвестиций.

Ответ 8

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

Ответ 9

Две хорошие причины для размещения бизнес-логики в базе данных:

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

Ответ 14

Основная причина, по которой я бы поставил BL в хранимых процедурах в прошлом, заключается в том, что транзакции были проще в базе данных.

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

Ответ 15

Я думаю Специально для более старых приложений, над которыми я работаю (в банке), где логика Бизнеса огромна, почти практически невозможно выполнить всю эту бизнес-логику на прикладном уровне, а также Это большой успех, когда мы ставим эту логику в слое Application, где число извлечения в базу данных больше, приводит к большему использованию ресурсов (больше java-объектов, если оно выполняется в слое java), а также к проблемам сети и забывает о производительности.

Ответ 16

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

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