Аргументы за / против Business Logic в хранимых процедурах

Question

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

Answer 1

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

Answer 2

СУБД! = Сервер приложений

• Функциональное программирование (хранимая процедура в БД) и ООП. Для больших программ ООП просто стандарт.
• IDE - eclipse, intellij, netbeans со всеми плагинами для отладки, тестирования и анализа работает только с реальными языками программирования. Инструменты статического кода .
• Контроль версий, если вы получаете один для PLSQL & co. отлично. Если вы получаете «синхронизировать вид» непосредственно из вашей IDE - вы действительно счастливчик.
• Масштабируйте свою систему. Для системы БД это ад. Вам нужно дорогое оборудование для других "узлов". Репликация. И, вероятно, лицензия для каждого узла. Не забывайте, что вы все еще занимаетесь «функциональным программированием», и усилия по пониманию и поддержке таких систем значительно больше.
• Вы застряли в своей БД, попробуйте изменить или добавить новую из другой компании
• И так далее ...

Хранимая процедура для бизнес-логики сегодня является плохой практикой. Вместо этого используйте 3-х уровневую архитектуру.

Answer 3

Мое эмпирическое правило (как только я понял, что это было, подумав о вопросе), заключается в том, что хранимые процедуры должны содержать код, который обеспечивает целостность данных в базе данных, независимо от того, запрещает ли хранимая процедура определенную вставку, удаление или изменение данных, или делает другие изменения, необходимые для согласованности данных. Бизнес-логика, особенно логика, которая не может быть реализована в нескольких операциях на основе множеств, должна быть реализована в другом месте. Базы данных не являются приложениями. Базы данных должны быть окончательным авторитетом для отношений и ограничений, даже если бизнес-правила также реализованы где-то еще, например, для обеспечения обратной связи в коде пользовательского интерфейса, который уменьшает обратные передачи с веб-сервера или устраняет ненужные попадания на занятый сервер. Можно спорить о том, включает ли «согласованность данных» результат сложной обработки сложных бизнес-правил, но я думаю, что обычно это становится понятным после понимания контекста. Не все бизнес-правила реализованы в виде отношений или ограничений данных. Не все операции в хранимой процедуре выполняются быстрее, чем код, выполняемый в отдельном процессе, даже в процессе, запущенном на отдельной машине в сети. Недавно я провел демонстрацию, показывающую, что многие операции в SSIS, например, (INSERT INTO () SELECT FROM), выполняются быстрее в SSIS, работающем по сети на отдельном компьютере, чем в хранимой процедуре (которая также вставляет результаты в базу данных). через сеть). Это почти невероятный результат (где SSIS работает быстрее, чем необработанные операторы SQL), и демонстрирует, что обнаружение наилучшей оптимизации любых проблем производительности происходит из реальности (тестирование), а не из логики, основанной только на нескольких концепциях. (Мы все еще должны принять решение о том, что тестировать, исходя из практического опыта.) (SSIS быстрее выполнялся за счет автоматической реализации многопоточности и конвейеров, использования BULK INSERT даже там, где это не было указано в необработанном операторе SQL, и отправки пакетов вставок в одном потоке при создании дополнительных BULK INSERT в других потоках. В этом случае он выполнялся примерно в два раза быстрее, чем необработанные операторы SQL. Драйверы обеспечивают самый быстрый доступ к данным, «прожженный на их языке», и хотя это может быть оправдано дополнительными (непризнанными ими) объяснениями, за этим стоит заблуждение.

Answer 4

Существуют разные виды «бизнес-логики». Рассмотрите возможность его разделения на основе того, как оно связано с другими уровнями или службами. Вот несколько практических правил с точки зрения MVC:

a) В базе данных (хранимая процедура), если она в основном связана с данными, и может быть выполнена с помощью объединений и относительно простых предложений WHERE и SELECT.

b) В контроллере, если он в основном связан с маршрутизацией или диспетчеризацией; то есть более крупномасштабное управление потоком пользовательского интерфейса с точки зрения выбора экрана или ресурса.

c) В модели или модели представления, если она включает сложные или сложные вычисления и / или условные выражения.

d) В представлении (например, в Razor), если это в первую очередь проблема с отображением, например, «дружественное» переформатирование и относительно простота реализации (Если это сложно, подумайте над тем, чтобы поместить его в модель представления.)

Answer 5

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

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

Answer 6

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

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

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

Answer 7

@ Ник "Я категорически против. Одна из главных причин - первая причина, о которой говорила Эйрино - она ​​живет в одном месте. Нельзя очень легко интегрировать ее в систему управления версиями. Иметь двух разработчиков практически невозможно. работая над хранимой процедурой одновременно. "

Не то чтобы я выступал за использование бизнес-логики для хранимых процедур (все наоборот). Но эти причины, которые вы выдвигаете, не имеют смысла. Хранимая процедура - это просто артефакт sql / DDL, который можно сохранить в системе управления версиями и который также является артефактом развертывания (то есть что-то, переданное dba для развертывания, почти так же, как вы передавали бы свою войну / слух). Артефакты для ИТ / развертывания) Один или несколько разработчиков могут работать над одной и той же хранимой процедурой вне системы управления исходным кодом точно так же, как вы будете делать с простым старым исходным кодом - путем ветвления, управления версиями и объединения.

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

Я работал в системах с огромным количеством кода, как на Java, так и на PLSQL / DDL, и все они были написаны с версией в открытом регистре. Все они рассматривались как исходный код, который должен быть скомпилирован и развернут в строгом процессе, над которым работают разные команды. Никогда не было проблем с тем, что вы описываете.

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