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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Я из школы мысли, которая говорит, что пока бизнес-логика:

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

Мне все равно, живет ли логика в хранимой процедуре, на среднем уровне J2EE, в экспертной системе клипов или где-либо еще. Независимо от того, где вы храните нашу бизнес-логику, «закон сохранения страдания» гарантирует, что кто-то скажет, что это неправильная идея, потому что компонент / хранилище X необходимо заменить на технологию / метод Y.

Answer 4

Некоторые мысли: обратите внимание, что это ответ, ориентированный на Java, но это основная часть моего недавнего (последних 10 лет) опыта

(1) Параллельная разработка (большой) командой разработчиков. Если ваше приложение достаточно сложное, что каждый разработчик не может создать свою собственную частную версию БД (с посещенными ссылками / ссылочными данными / и т. Д.), Очень трудно заставить целую КОМАНДУ разработчиков работать над один и тот же набор пакетов PL-SQL (например) одновременно хранится в общей базе данных DEVL? Тогда вы застряли (мой опыт) с работой в БД с неверными процедурами / несоответствием кода таблицам, когда люди вносят изменения ...

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

(2) Наборы инструментов для непрерывной интеграции Хотя в мире БД существуют некоторые похожие «концепции», мой опыт показал мне, что комбо (я выбираю свои лучшие фавориты в этой области):

• mvn - сборка системы
• junit - автоматизированное модульное тестирование
• nexus - менеджер репо (управляет версией жизненного цикла артефакта, снимками и выпусками)
• hudson - ci build server
• sonar - инструмент статического анализа / отчеты о покрытии кода / ALOT более

Выполнение большого проекта с использованием всего вышеперечисленного (бесплатные инструменты) позволяет согласованно / легко доставить XP в массы и обеспечить контроль качества всего ИТ-персонала. Oracle / PL-SQL не имеет наборов инструментов для соответствия

(3) инструменты / библиотеки / и т.д ... У Java есть доступ к удивительному набору сервисов, которые другие платформы не могут использовать - некоторые бесплатные, некоторые нет. даже базовые, такие как log4j (да, они есть для PL / SQL, но, пожалуйста, не совсем так), позволяют разработчикам создавать гибко настраиваемые журналы, которые можно изменять на лету (идеально подходит для дублирования) , Автоматизированная документация по API (через javadoc). Автоматизированные отчеты о покрытии модульных испытаний. Невероятные IDE (Eclipse) со встроенными отладчиками / автоматическое развертывание на серверах приложений. API для взаимодействия со всеми типами сервисов под солнцем, библиотеки с открытым исходным кодом для НИЧЕГО и 100% поддержки от каждого поставщика

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

Но то же самое можно сказать и о бизнес-правилах, которые не управляются данными или являются достаточно сложными, чтобы ОО был более естественным выбором . Если вы вставите ВСЕ бизнес-логику в БД, то они будут доступны только через БД.

• Что делать, если вы хотите, чтобы проверка выполнялась на уровне клиента или среднего уровня приложения и сохранялась в обе стороны в БД?
• Что если вы хотите кэшировать данные только для чтения на среднем уровне (для производительности) и выполнять бизнес-правила для кэшированных данных?
• Что если у вас есть служба среднего уровня, которая не требует доступа к БД, или у вас есть клиент, который может предоставлять свои собственные данные?
• Что если зависимой от данных части бизнес-правил потребуется доступ к внешним службам? Затем вы заканчиваете фрагментированной бизнес-логикой, которая выглядит следующим образом:

я

retCode = validateSomeDate(date);
if (retCode == 1) then
   evaluateIfCustomerGetsEmail(...)//probably more stored proc invocations here...
   sendEmailMsg(....)
else if (retCode == 2) then
   performOtherBizLogicStuf(...) //again, may need data, may not need data
   triggerExternalsystemToDoSomething(...) //may not be accessible via PL/SQL 
fi

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

Answer 5

«Вы не можете легко интегрировать его в систему контроля версий». - если вы поместите код, который создает хранимый процесс в сценарий, который контролируется версией, это возражение исчезнет. Если вы следуете идеям гибкой базы данных Скотта Амблера, это именно то, что вам следует делать.

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

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

SOA предлагает средний путь: сервисы владеют своими данными. Только сервис имеет доступ к данным; добраться до данных означает пройти через сервис. В этом случае можно поместить правила в любом месте.

Приложения приходят и уходят, но данные остаются.

Answer 6

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

Answer 7

Мои несколько наблюдений:

В пользу хранимых процедур:

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

• Использование SQL-профилировщика с ORM-генерируемыми SQL-запросами очень сложно; это легко с хранимыми процедурами

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

• для производительности проще оптимизировать хранимую процедуру, чем ORM-код

• у вас может быть много приложений, использующих одни и те же дб / хранимые процы

• любой сложный сценарий данных - это голосование за хранимые процедуры

В пользу заявки / ORM:

• вы можете использовать хранилище кода (с сохраненными процессами это все еще возможно, но дорого)

• язык java / c # - лучший инструмент для выражения бизнес-логики

• java / c # легче отлаживать (кроме динамически генерируемого sql ORM)

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

• ORM предоставляет модель данных, которая проста в использовании

На мой взгляд: для больших проектов - перейти на хранимые процедуры, для других - приложение / ORM будет работать нормально.

В конце концов, единственное, что имеет значение, это база данных.

Answer 8

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

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

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

Проверка выполняется, если логика находится только в базе данных. Вы действительно вызываете sproc для проверки каждого поля в форме ввода данных? Правила валидации и бизнес-логика - близкие родственники. Эта логика должна выполняться в одном месте!

Answer 9

Есть поговорка ...

Когда у тебя есть только молоток, все выглядит как гвоздь.

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

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

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

Если нет, то делай это в другом месте.

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

Это только мои 2 цента.

Answer 10

+: SQL-сервер иногда оптимизирует код

+: Вы вынуждены передавать параметры, что ограничивает проблемы внедрения SQL

-: Ваш код зависит от одной базы данных (некоторые базы данных даже не имеют SP)

-: для изменения кода необходимо подключиться к базе данных

-: Логика не организована хорошо

Лично я против этого, но мне приходилось использовать это один раз на очень загруженном сайте. Использование SP в MS SQL принесло огромные преимущества, но как только я реализовал кэширование, эти преимущества перестали быть такими большими.