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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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