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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

(2) Инструменты непрерывной интеграции Несмотря на то, что в мире БД существует несколько подобных "понятий", мой опыт показал мне, что комбо (я выбираю здесь свои лучшие лучшие в своем роде):

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

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

(3) инструменты/библиотеки/etc... Java имеет доступ к удивительному набору услуг, которые другие платформы не могут коснуться - некоторые бесплатные, а некоторые нет. даже базовые, такие как log4j (да, у них есть это для PL/SQL, но pulease... это не то же самое) позволяет такие вещи, как позволить разработчикам создавать гибко настраиваемые протоколирования, которые можно менять "на лету" (идеально подходит для dubugging), Автоматизированная документация API (через javadoc). Автоматизированные отчеты об охвате unit test. Невероятные IDE (Eclipse) со встроенными отладчиками /autodeploy для серверов приложений. API для взаимодействия с каждым типом службы под солнцем, с открытым исходным кодом для БЕСПЛАТНО и 100% поддержки каждого поставщика

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

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

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

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 утра. Крайне сложно получить согласованное чувство сложного процесса, когда бизнес-логика фрагментирована между уровнями, а в некоторых случаях ее невозможно поддерживать.

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

В пользу приложения /ORM:

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

+: вы вынуждены передавать параметры, которые ограничивают проблемы SQL-инъекций

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

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

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

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

Ответ 10

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

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

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

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

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

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

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

Это всего лишь мои 2 цента.

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

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

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

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

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

Ответ 15

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

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

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

Ответ 16

Проекты с высоким бюджетом: если вы сохраняете свои последние данные в памяти и периодически сохраняете изменения на диске, вам нужно будет обрабатывать бизнес-логику, кроме сервера db. use case: обслуживать данные из ram, сложные механизмы кэширования.

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

Ответ 17

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

Ответ 18

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

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

Наличие такого контр-мыслительного процесса всегда будет направлять принятие правильного решения. Задайте эти вопросы, прежде чем принять решение:

Что если в дальнейшем мы изменим нашу базу данных с SQL на Mongo?
Что, если вы хотите предоставить API, который берет данные (которые предоставляет база данных) и применяет эту бизнес-логику сверху?
Модульное тестирование этой бизнес-логики?
Шаги SDLC, если мы внесем изменения в условия этой бизнес-логики?
Что если нам понадобится другой пользовательский ввод для принятия решений в этой бизнес-логике?
Что если требуется высокая вычислительная мощность (не обработка данных), и мы хотим запустить отдельный процесс (или платформу)?

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