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

Сотни форм, журналов, справочников, БД объёмом несколько сотен ГБ. Есть большое желание перевести клиентскую часть на новую платформу, при этом БД желательно не трогать совсем или трогать по минимуму. Рассматриваем голый и . Если с всё более-менее понятно - практически полная свобода действий в плане взаимодействия с БД, создания интерфейсов - всё ограничено только доступным набором компонентов, и есть только один минус - требуется время на разработку своей мини-платформы, то у как у готовой платформы скорее всего ограничений больше, в связи с чем возник ряд вопросов, буду очень благодарен, если смогу получить на них ответы: Все сущности в БД создаются, обновляются и удаляются через вызовы хранимых процедур - в них скрыта практически вся бизнес-логика работы системы. Процедуры требуют для своей работы временную таблицу, содержащую сущности для обработки. Как это будет выглядеть на - хотя бы примерное направление действий, и так чтобы не писать кучу кода для каждой сущности каждый раз Есть журналы, которые формируются на основе данных, возвращаемых из хранимых процедур и табличных функций, которые имеют набор входных параметров фильтров - дата, клиент, и т. Такие журналы могут быть связаны с другими сущностями в системе, из журналов могут открываться карточки редактирования объектов, другие журналы например детализация суммарного показателя и т.

# — Мнение о создании бизнес-уровня по миграции устаревшей системы

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

. Серверное ядро является неизменяемым компонентом системы.

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

, а от расширенных хранимых процедур в будущем планируется отказаться. Также процедуры на и С поддерживает . Пакет состоит из двух частей — спецификации англ. Таким образом позволяет отделить интерфейс программного кода от его реализации. Назначение и преимущества хранимых процедур [3] [ править править код ] Хранимые процедуры позволяют повысить производительность, расширяют возможности программирования и поддерживают функции безопасности данных.

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

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

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

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

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

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

Модель сервера баз данных

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

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

Почему я не пишу логику на - 18 Августа Программирование 2 0 Совсем недавно я написал о задании для программиста, которое мне прислали, где нужно было найти натуральные числа на - читаем заметку здесь. Там было ещё два задания, которые я точно не помню, но смысл в том, что они легко решаемы, но нужно писать процедуру или какой-то другой код на стороне - . В той заметке я так же спросил, что говорит такое задание. И объясню почему. Если переносить логику на базу данных, то на неё увеличивается нагрузка.

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

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

Хранимая процедура

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

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

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

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

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

Стоит ли переносить часть бизнес логики на БД?

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

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

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

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

Где место бизнес логике?

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

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

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

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

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

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

Хранимые функции и бизнес-логика

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

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

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

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

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

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

Фрагмент видео-урока"SQL для аналитиков"