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

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

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

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

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

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

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

Это можно интерпретировать как включение принудительного применения ограничений на данные (он же "бизнес-правила"). Исполнение этих недвусмысленно относится к СУБД, период.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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