зачем использовать хранимые процедуры
Хранимые процедуры: описание, лимиты и примеры
В этой статье я расскажу о хранимых процедурах. Как их использовать и зачем, лимиты, примеры крутых процедуры которые я использую.
Хранимые процедуры позволяют исполнять код на стороне сервера API аналогично методу execute, но без передачи кода процедуры по сети.
Хранимая процедура — это заданный алгоритм, позволяющий Вам реализовать быстрый вызов сразу нескольких методов API, аналогично принципу работы метода execute, но без передачи кода по сети (в запросе необходимо указывать только имя процедуры и необходимые параметры).
Создавать новые хранимые процедуры Вы можете на соответствующей вкладке раздела редактирования Вашего приложения.
Код для хранимых процедур пишется на VKScript языке.
VKScript для метода execute получается не всегда маленький, и передавать его в запросе очень жирно. Так же для хранимых процедур реализован удобный клиент прямо в Вконтакте. Дергать процедуру по ее названию, в этом случае передавать code уже не нужно. Не используя хранимые процедуры при отправке запросов с клиента, ваш код отправляемый к API, можно посмотреть.
Отправляя код с браузера к API, его может посмотреть любой человек. При отправке только названия хранимой процедуры и параметров, код будет не доступен.
Назначение хранимых процедур в языке T-SQL (Microsoft SQL Server)
Приветствую Вас на сайте Info-Comp.ru! Из данного материала Вы узнаете, для чего нужны хранимые процедуры в языке T-SQL, мы рассмотрим основные возможности хранимых процедур и преимущества их использования.
Хранимые процедуры в T-SQL
Хранимая процедура – это объект базы данных, который хранит набор инструкций языка T-SQL, реализующих определённый алгоритм.
Хранимые процедуры используются в языке T-SQL для реализации бизнес логики, каких-то алгоритмов, расчетов, а также для написания различных инструкций администрирования баз данных и сервера, которые периодически необходимо выполнять.
Иными словами, хранимые процедуры – это своего рода программы внутри базы данных, которые хранят реализованный нами алгоритм, и в случае запуска этих программ выполняют этот алгоритм.
Примечание! В данном материале речь идет о пользовательских хранимых процедурах, которые создаем мы с Вами, т.е. программисты T-SQL.
Назначение хранимых процедур в T-SQL
Чтобы ответить на вопрос: для чего нужны хранимые процедуры? и определить их назначение, необходимо рассмотреть возможности, которые нам предоставляют хранимые процедуры, и те преимущества, которые мы получим, если будем их использовать. Именно это и определяет назначение хранимых процедур, т.е. для чего они созданы.
Возможности хранимых процедур
Преимущества хранимых процедур
Повышение безопасности
Использование хранимых процедур повышает безопасность по нескольким причинам:
Устранение дублирования кода
SQL код, включающий многошаговые операции с базой данных, который многократно используется в приложении в разных местах, можно вынести в хранимую процедуру, тем самым устранить необходимость копирования одного и того же кода. Как результат, у Вас уменьшится общий объем кода за счет отсутствия повторяющихся участков кода.
Легкое сопровождение кода
Когда весь SQL код и заложенный в нем алгоритм вынесен в хранимые процедуры, а клиентское приложение лишь осуществляет вызов этих процедур, то сопровождать такое приложение становится гораздо легче. Ведь в случае возникновения необходимости внести изменение в алгоритм работы с данными, который заложен в хранимой процедуре, достаточно один раз внести изменение в базу данных в код хранимой процедуры. Иными словами, нет необходимости вносить изменения в само клиентское приложение, перекомпилировать и осуществлять обновление.
Кроме этого вынесение всего SQL кода в хранимые процедуры снизит уровень несогласованности кода клиентского приложения, и таких ситуаций возникать не будет, когда в одном месте SQL код выполняет одни изменения в базе данных, а вроде бы тот же самый SQL код, но в другом месте, выполняет совершенно другие изменения в базе данных. С хранимыми процедурами Вы будете вносить изменения только в одном месте – в исходном коде хранимой процедуры.
Повышение производительности
Microsoft SQL Server компилирует хранимую процедуру и создает план выполнения один раз, а затем повторно использует этот план выполнения. Это приводит к повышению производительности в случае многократного вызова хранимой процедуры, ведь теперь обработчику запросов не нужно создавать новый план и поэтому обработка процедуры занимает меньше времени.
Примечание! Если в таблицах и в данных, с которыми работает хранимая процедура, произошли значительные изменения, то наличие предварительно скомпилированного плана наоборот может вызвать замедление работы процедуры. В этом случае необходимо принудительно перекомпилировать процедуру, и тем самым создать новый план выполнения.
Сокрытие сложности
В разработке приложения нередко участвуют достаточно много разработчиков, а если говорить о крупных информационных системах, то разработчики могут исчисляться и сотнями. При этом одни программисты разрабатывают интерфейс клиентского приложения, а другие разрабатывают базу данных и всю логику работы с ней.
И в таких ситуациях разработчикам, которые работают с интерфейсом клиентского приложения, совсем необязательно знать алгоритм выполнения определённых действий в базе данных, который заложен в SQL инструкциях. Более того, они не должны его знать.
Хранимые процедуры как раз и скрывают алгоритм действий в базе данных и всю его сложность. Иными словами, если, например, разработчику клиентского приложения потребовалось использовать функционал добавления нового пользователя этого приложения, то он должен знать только название хранимой процедуры и описание ее параметров, а что конкретно она там делает и как именно создает пользователя, он знать не должен.
Использование хранимых процедур T-SQL является преимуществом и для разработчиков интерфейса приложения, так как в этом случае им просто легче программировать, им не нужно писать запутанные SQL инструкции, они могут просто вызывать хранимые процедуры, более того, так у них формируется полноценная абстракция их классов, в случае с ООП.
Снижение сетевого трафика между клиентами и сервером
Использование хранимых процедур позволяет существенно сократить сетевой трафик между сервером и клиентом, так как по сети отправляется только вызов на выполнение хранимой процедуры. Иными словами, без инкапсуляции кода, предоставляемой процедурой, по сети нам бы пришлось пересылать все строки кода, которых может быть достаточно много.
Подведение итогов
Давайте подведем итог на основе всего вышесказанного и сформулируем итоговое назначение хранимых процедур в языке T-SQL.
Хранимые функции. За и против
Использование хранимых функций СУБД для реализации бизнес-логики или её части, всегда было камнем преткновения. С одной стороны баррикад DBA и программисты БД, с другой — разработчики backend.
Рискну навлечь на себя гнев из обоих лагерей, но всё же просуммирую плюсы и минусы и изложу свои соображения о том, когда стоит писать код в хранимых функциях, а когда следует выносить наружу.
Начнём с аргументов против:
Размазывание бизнес-логики
Это, на самом деле не проблема СУБД и ХФ, как инструмента — это проблема их неверного использования. У программиста бд может возникнуть желание описать всю логику реализуемого действия в хранимой функции — действительно, ведь все данные вот они, под рукой. Если программист поддастся на искушение, а его руководитель не возразит, в будущем могут возникнуть проблемы с узостью интерфейса со внешней системой (например, с сервером приложений) — придётся добавлять новые параметры, усложнять логику и т.п. Это даже может привести к тому, что появятся «дублирующие» ХФ со слегка иным функционалом.
Скудность языка СУБД
Есть такое дело. Традиционные языки для написания ХФ pl/sql, t-sql, pl/pgsql довольно примитивны по сравнению с современными языками общего назначения. Стоит заметить, что есть возможность писать ХФ и на более продвинутых языках, например Java в Oracle или Python в postgresql.
Непереносимость хранимых функций
Имеется в виду несовместимость диалектов процедурных языков разных СУБД. Многоплатформенность как раз на уровне — благодаря поддержке разных ОС и архитектур в самих СУБД и независимости встроенных языков от внешней платформы. Здесь опять решение зависит от специфики проекта. Если проект тиражируемый, причём вы не контролируете платформу (классический пример — CMS), то переносимость вам необходима и использование ХФ — только добавит головной боли. Если же проект уникальный, либо внедрения будут происходить унифицировано (например в разных филиалах одной компании), то про непереносимость между разными СУБД можно забыть.
Отсутствие необходимых навыков у команды и высокая «стоимость» соответствующих специалистов
Это, на мой взгляд, самый серьёзный аргумент против использования ХФ. Тут всё зависит от масштабов проекта. Грубо говоря, использование хранимого кода на стороне СУБД оправдано в средних-крупных enterprise проектах. Если проект помельче — овчинка выделки не стоит. Если проект огромный сверхнагруженный, то архитектура с ХФ и РСУБД упрётся в проблемы масштабирования — тут необходимо использование специфического хранилища и подхода к обработке данных.
Скорость
При обработке даже небольших объёмов данных во внешнем приложении мы тратим дополнительное время на передачу по сети и преобразование данных в нужный нам формат. К тому же в СУБД уже встроены, отлажены и протестированы близкие к оптимальным алгоритмы обработки данных, вашим программистам незачем практиковаться в изобретении велосипедов.
Сокрытие структуры данных
С ростом и эволюцией программной системы схема данных может и должна меняться. Хорошо спроектированный программный интерфейс на ХФ позволит менять схему данных не изменяя код внешних приложений (которых может быть несколько). Отсюда органично вытекает и разделение ролей разработчиков, которые работают с БД и знают её структуру, и разработчиков внешних приложений, которые должны знать лишь предоставляемый API. При использовании динамического SQL на стороне приложения, для подобного разделения вводятся дополнительные слои программных абстракций БД, различные ORM.
Гибкое управление правами доступа
Хорошей практикой является ограничение пользователя, под которым «ходит» в базу клиентское приложение в правах таким образом, что он не имеет прав на чтение и изменение никаких объектов. Лишь выполняет разрешённые ему функции. Таким образом можно жёстко контролировать какие действия доступны клиенту, уменьшается вероятность нарушения целостности данных из-за ошибки клиентского приложения.
Меньшая вероятность SQL injection
При использовании динамического SQL со стороны клиентской программы, клиентская программа передаёт СУБД SQL команды в виде строк, предварительно формируемых в коде. При формировании этих строк программисту нужно быть предельно внимательным, чтобы не допустить возможности непредусмотренной модификации SQL команды. При использовании ХФ SQL код на стороне приложения обычно статический, и выглядит, как простой вызов ХФ, параметры которой передаются не строками, а через placeholders (:variable) через механизм binding. Конечно это не исключает возможность SQL injection полностью (ведь можно умудриться в ХФ конкатенировать строку, переданную параметром с текстом динамически выполняемого SQL запроса), но значительно уменьшает её вероятность.
Повторное использование SQL
Реализуя логику работы с данными в хранимом слое мы получаем привычную нам иерархическую модель повторного использования SQL кода.
При использовании динамического SQL повторное использование запросов затруднено.
Например пусть есть система A на базе ХФ и система Б на базе динамического SQL. В обеих системах есть функция получения цены товара get_price. В случае A — это хранимая функция или отображение (view), в случае Б, допустим, процедура на java, через JDBC выполняющая SQL запрос. Есть задача — получить общую стоимость товара на складе. В случае A мы джоиним get_price прямо в запрос, получающий список товаров на складе (в случае, если get_price — view или ХФ на SQL, как например в PostgreSQL, то оптимизатор разворачивает запрос inline — тем самым получается один запрос, который быстро находит сумму).
В случае B есть два варианта — либо пробежать по курсору с выборкой товаров на складе и n раз вызвать get_price (а это значит что вся выборка должна передаться по сети на клиент) либо забыть про повторное использование и написать подзапрос, дублирующий тот, что был уже написан в get_price. Оба варианта — плохие.
Простая отладка SQL
Упрощается отладка (по сравнению с разнородной процедурой внешний код+sql)
В системах с динамическим SQL (любые ORM) даже простая задача поиска проблемного куска SQL может оказаться сложной.
Семантическая и синтаксическая проверка SQL на этапе компиляции.
Возможность профилирования функций и поиска узких мест.
Возможность трассировки уже запущеной и работающей системы.
Автоматический контроль зависимостей — при изменении определения объекта инвалидируются зависимые сущности.
Когда писать бизнес-логику в БД?
Если важна скорость обработки данных
Обработка данных прямо на месте их хранения зачастую даёт значительный прирост скорости обработки. Становятся возможными такие оптимизации, как, например, агрегации на уровне хранилища данных — данные с массива даже не передаются на сервер СУБД, не говоря о клиенте.
Когда важна целостность и непротиворечивость данных
В хранимых функциях с явным управлением транзакциями и блокировками проще обеспечить целостность данных и атомарность операций. Конечно всё это может быть реализовано и снаружи, но это отдельная и большая работа.
Данные имеют сложную, но устоявшуюся структуру
Плоские и слабо взаимосвязанные структуры часто не требуют всего богатства инструментов обработки, которые предлагают СУБД. Для них можно использовать сверхбыстрые key-value хранилища и кеширование в памяти.
Сложно организованные сильно связанные иерархические и сетевые структуры — явный показатель, что ваши знания РСУБД пригодятся!
Когда выносить код наружу?
Работа с внешними данными
Если специфика системы такова, что данных, приходящих на обработку снаружи (с датчиков, из других систем) больше, чем данных, сохраняемых в БД, то многие плюсы БД, как платформы программирования теряются. Оказывается проще обработать поступающие даннные снаружи и сохранить результат в БД, чем сначала всё пихать в БД, а потом обрабатывать. Здесь соблюдается тот же принцип — обрабатывать данные как можно ближе к источнику, о котором мы говорили выше применительно обработке данных, уже хранящихся в БД.
Сложные алгоритмы
Сложные или высоко-оптимизированные алгоритмы-числодробилки лучше писать на более приспособленных для этого языках. Встроенные языки РСУБД очень мощны (в том смысле, что высокоуровневые, а не гибкие), но за счёт этого имеют высокий overhead.
Highload
В сверхвысоконагруженных системах обычные подходы к сериализации транзакций и синхронизации серверов кластера становятся узким местом. Для таких систем характерны уникальные решения под конкретные задачи, универсальные и мощные системы РСУБД часто оказываются слишком медлительными при нагрузках в сотни тысяч конкурентных транзакций в секунду.
Вывод такой, что чёткого алгоритма нет. Каждый раз решение остаётся за архитекторами и менеджером и от него зависит то, завязнет ли проект в проблемах с race conditions и неконсистентностью данных NoSQL, проблемах с производительностью и отладкой запросов ORM, или упрётся в проблемы масштабирования СУБД при использовании хранимых функций. Поэтому — принимайте верные решения 🙂
Т.к. подобный запрос мы будем использовать каждый раз, когда нам необходимо будет добавить нового покупателя, то вполне уместно оформить его в виде процедуры:
Обратите внимание, как задаются параметры: необходимо дать имя параметру и указать его тип, а в теле процедуры мы уже используем имена параметров. Один нюанс. Как вы помните, точка с запятой означает конец запроса и отправляет его на выполнение, что в данном случае неприемлемо. Поэтому, прежде, чем написать процедуру необходимо переопределить разделитель с ; на «//», чтобы запрос не отправлялся раньше времени. Делается это с помощью оператора DELIMITER // :
Таким образом, мы указали СУБД, что выполнять команды теперь следует после //. Следует помнить, что переопределение разделителя осуществляется только на один сеанс работы, т.е. при следующем сеансе работы с MySql разделитель снова станет точкой с запятой и при необходимости его придется снова переопределять. Теперь можно разместить процедуру:
Согласитесь, что так гораздо проще, чем писать каждый раз полный запрос. Проверим, работает ли процедура, посмотрев, появился ли новый покупатель в таблице Покупатели (customers):
Как было сказано в начале урока, процедуры позволяют объединить последовательность запросов. Давайте посмотрим, как это делается. Помните в уроке 11 мы хотели узнать, на какую сумму нам привез товар поставщик «Дом печати»? Для этого нам пришлось использовать вложенные запросы, объединения, вычисляемые столбцы и представления. А если мы захотим узнать, на какую сумму нам привез товар другой поставщик? Придется составлять новые запросы, объединения и т.д. Проще один раз написать хранимую процедуру для этого действия.
Казалось бы, проще всего взять уже написанные в уроке 11 представление и запрос к нему, объединить в хранимую процедуру и сделать идентификатор поставщика (id_vendor) входным параметром, вот так:
А потом создадим запрос, который просуммирует суммы поставок интересующего нас поставщика, например, с id_vendor=2:
Вот теперь мы можем объединить два этих запроса в хранимую процедуру, где входным параметром будет идентификатор поставщика (id_vendor), который будет подставляться во второй запрос, но не в представление:
Проверим работу процедуры, с разными входными параметрами:
Как видите, процедура срабатывает один раз, а затем выдает ошибку, говоря нам, что представление report_vendor уже имеется в БД. Так происходит потому, что при обращении к процедуре в первый раз, она создает представление. При обращении во второй раз, она снова пытается создать представление, но оно уже есть, поэтому и появляется ошибка. Чтобы избежать этого возможно два варианта.
Перед использованием этого варианта не забудьте удалить процедуру sum_vendor, а затем проверить работу: 
Как видите, сложные запросы или их последовательность действительно проще один раз оформить в хранимую процедуру, а дальше просто обращаться к ней, указывая необходимые параметры. Это значительно сокращает код и делает работу с запросами более логичной.
Видеоуроки php + mysql
Если этот сайт оказался вам полезен, пожалуйста, посмотрите другие наши статьи и разделы.
Вред хранимых процедур
В чат подкаста «Цинковый прод» скинули статью о том, как некие ребята перенесли всю бизнес-логику в хранимые процедуры на языке pl/pgsql. И так как у статьи было много плюсов, то значит, есть люди, а может быть, их даже большинство, которые положительно восприняли такой рефакторинг.
Я не буду растекаться мысью по древу, а сразу накидаю кучку минусов использования хранимых процедур.
Минусы хранимых процедур
Версионирование
Если в случае с кодом на php вы можете просто переключиться в git на другую ветку и посмотреть, что получилось, то хранимые процедуры нужно еще засунуть в базу. И традиционные миграции тут плохо помогут: если записывать все изменения хранимок как новый CREATE OR REPLACE PROCEDURE, то на кодревью будет ад: всегда новый файл, который непонятно с чем сравнивать. Поэтому придется искать какие-то дополнительные инструменты или писать свой велосипед.
Сам язык pl/pgsql
Это устаревший процедурный язык из девяностых, который вообще никак не развивается. Никакого ООП или ФП или чего бы то ни было. Синтаксис без малейшего намека на синтаксический сахар.
Например, переменные нужно объявлять в начале процедуры, в специальном блоке DECLARE. Так делали наши деды, в этом есть некая ностальгия по языку Pascal, но спасибо, не в 2020.
Сравните две функции, которые делают одно и то же на php и pl/pgsql:
Примерно в 2-3 раза больше писанины.
Кроме того, язык интерпретируемый, без JIT и т.д. (поправьте меня, если что-то изменилось в последних версиях). Т.е. все очень медленно и печально. Уж если использовать какие-то хранимки, то на чистом SQL или v8 (т.е. javascript).
Отладка
Поверьте, отлаживать код на php в 100500 раз проще. Ты просто поправил что-то и смотришь результат. Можно обложить echo или смотреть, что там через xdebug прямо в IDE.
Отладка хранимых процедур — это неудобно. Это надо делать в pgadmin (включив специальное расширение). PgAdmin — это далеко не PHPstorm по удобству.
Логирование и обработка ошибок
Забудьте о том, чтобы красивый json c трейсом падал с stdout, а потом в graylog и в sentry. И чтобы все это автоматически происходило, выдавая пользователю ошибку 500, в случае если контроллер не поймал exception.
В хранимках pl/pgsql вы всё будете делать вручную:
Сбор метрик
Вы не можете, как в golang, просто добавить эндпоинт /metrics, который будет подсасываться Прометеусом, куда вы напихаете бизнесовые и другие метрики для мониторинга. Я просто не знаю, как тут выкрутиться с pl/pgsql.
Масштабирование
Выполнение хранимых процедур тратит ресурсы (например, CPU) сервера базы данных. В случае других языков вы можете вынести логику на другие ноды.
Зависимости
В php вы, используя пакетный менеджер composer, одним движением можете подтянуть нужную библиотеку из интернета. Точно так же как в js это будет npm, в Rust это будет cargo и т.д.
В мире pl/pgsql нужно страдать. В этом языке просто нет менеджера зависимостей.
Фреймворки
В современном мире веб-приложение часто не пишут с нуля, а собирают на основе фреймворка, используя его компоненты. К примеру, на Laravel у вас из коробки есть роутинг, валидация запроса, движок шаблонов, аутентификация/авторизация, 100500 хелперов на все случаи жизни и т.д. Писать всё это вручную с нуля, на устаревшем языке — ну нет, спасибо.
Получится много велосипедов, которые потом еще и поддерживать придется.
Юнит-тесты
Сложно даже представить, как удобно организовать unit-тесты в хранимках на pl/pgsql. Я ни разу не пробовал. Поделитесь пожалуйста в комментариях.
Рефакторинг
Несмотря на то, что существует IDE для работы с базой данных (Datagrip), для обычных языков средства рефакторинга гораздо богаче. Всевозможные линтеры, подсказки по упрощению кода и т.д.
В случае с plpgsql — тишина.
Плюсы хранимых процедур
Выводы
На мой взгляд, хранимые процедуры нужны только в очень-очень редких случаях, когда вы уверены, что вы без них вообще не можете обойтись. В остальных кейсах — вы только усложните жизнь разработчикам, причем существенно.
Я бы понял, если в исходной статье часть логики переложили на SQL, это можно понять. Но зачем хранимки — это загадка.
Буду рад, если вы считаете, что я неправ или знаете, какие-то еще ситуации, связанные с хранимыми процедурами (как плюсы, так и минусы), и напишете об этом в коменты.