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

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

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

1. It becomes confusing where the logic is,
2. Typically databases are a silo and do not scale horizontally nearly as well as the app servers.
3. t_sql/PLsql is hard to read and procedural in nature
4. You forfeit all of the benefits of OOAD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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