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

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

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

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

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

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

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

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

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

Его можно интерпретировать как включающее в себя обеспечение ограничений на данные (так называемые «бизнес-правила»). Обеспечение их соблюдения однозначно относится к dbms, period.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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