Хранимая процедура
Эта статья нуждается в дополнительных цитатах для проверки . ( июнь 2024 г. ) |
( Хранимая процедура также называемая prc , proc , storp , sproc , StoPro , StoredProc , StoreProc , sp или SP ) — это подпрограмма , доступная приложениям, которые обращаются к системе управления реляционными базами данных (СУБД). Такие процедуры хранятся в словаре данных базы данных .
Использование хранимых процедур включает механизмы проверки данных (интегрированные в базу данных) или контроля доступа . Более того, хранимые процедуры могут консолидировать и централизовать логику, которая изначально была реализована в приложениях. Чтобы сэкономить время и память, обширную или сложную обработку, требующую выполнения нескольких операторов SQL, можно сохранить в хранимых процедурах, и все приложения будут вызывать эти процедуры. Можно использовать вложенные хранимые процедуры, выполняя одну хранимую процедуру из другой.
Хранимые процедуры могут возвращать наборы результатов , т. е. результаты SELECT
заявление. Такие наборы результатов могут обрабатываться с помощью курсоров , других хранимых процедур, путем связывания локатора набора результатов или приложений. Хранимые процедуры также могут содержать объявленные переменные для обработки данных и курсоры, которые позволяют циклически перемещаться по нескольким строкам таблицы. Операторы управления потоком хранимых процедур обычно включают в себя IF
, WHILE
, LOOP
, REPEAT
, и CASE
заявления и многое другое. Хранимые процедуры могут получать переменные, возвращать результаты или изменять переменные и возвращать их, в зависимости от того, как и где объявлена переменная.
Реализация [ править ]
Хранимые процедуры аналогичны пользовательским функциям (UDF). Основное отличие состоит в том, что пользовательские функции могут использоваться как любое другое выражение в операторах SQL, тогда как хранимые процедуры должны вызываться с использованием CALL
заявление. [1]
CALL procedure(...)
или
EXECUTE procedure(...)
Точная и правильная реализация хранимых процедур варьируется от одной системы баз данных к другой. Большинство крупных поставщиков баз данных поддерживают их в той или иной форме. В зависимости от системы базы данных хранимые процедуры могут быть реализованы на различных языках программирования , например SQL , Java , C или C++ . Хранимые процедуры, написанные на языках, отличных от SQL, могут сами выполнять инструкции SQL, а могут и не выполнять их.
Растущее внедрение хранимых процедур привело к введению процедурных элементов в язык SQL в стандартах SQL:1999 и SQL:2003 в части SQL/PSM . Это сделало SQL обязательным языком программирования . Большинство систем баз данных предлагают собственные и зависящие от поставщика расширения, превосходящие SQL/PSM. Существует стандартная спецификация для хранимых процедур Java, а также SQL/JRT .
Система баз данных | Язык реализации |
---|---|
КУБРИД | Ява |
IBM DB2 | SQL PL (близкий к стандарту SQL/PSM ) или Java |
Жар-птица | PSQL (Fyracle также поддерживает части Oracle PL/SQL) |
Информикс | Ява |
Интербаза | Хранимая процедура и язык триггеров |
Microsoft SQL-сервер | Transact-SQL и различные .NET Framework языки |
MySQL , МарияДБ | собственные хранимые процедуры, строго соответствующие SQL/PSM стандарту |
НуоБД | SQL или Java |
Виртуоз OpenLink | Виртуозные процедуры SQL (VSP); [2] также расширяется с помощью Java, C и других языков программирования. |
Оракул | PL/SQL или Java |
PostgreSQL | PL/pgSQL также может использовать собственные языки функций, такие как PL/Tcl, PL/Perl или PL/Python. [3] |
SAP Хана | SQLScript или R |
SAP АСЭ | Транзакт-SQL |
SAP SQL в любом месте | Transact-SQL , Watcom SQL |
SQLite | Не поддерживается |
Сравнение со статическим SQL [ править ]
- Накладные расходы
- Поскольку операторы хранимых процедур хранятся непосредственно в базе данных, они могут полностью или частично устранить накладные расходы на компиляцию, которые обычно необходимы, когда программные приложения отправляют встроенные (динамические) запросы SQL в базу данных. (Однако большинство систем баз данных реализуют операторов кэши и другие методы, чтобы избежать повторной компиляции динамических операторов SQL.) Кроме того, хотя они и избегают использования предварительно скомпилированного SQL, операторы усложняют создание оптимального плана выполнения, поскольку не все аргументы SQL оператор предоставляется во время компиляции. В зависимости от конкретной реализации и конфигурации базы данных будут наблюдаться неоднозначные результаты производительности хранимых процедур по сравнению с общими запросами или пользовательскими функциями.
- Избегание сетевого трафика
- Основным преимуществом хранимых процедур является то, что они могут выполняться непосредственно внутри ядра базы данных . В производственной системе это обычно означает, что процедуры полностью выполняются на специализированном сервере базы данных с прямым доступом к данным. Преимущество состоит в том, что это экономит сетевые затраты, что особенно заметно, когда используется серия операторов SQL.
- Инкапсуляция бизнес-логики
- Хранимые процедуры позволяют программистам встраивать бизнес-логику в виде API в базу данных, что может упростить управление данными и уменьшить необходимость кодирования логики в других местах клиентских программ. Это может привести к снижению вероятности повреждения данных неисправными клиентскими программами. Система базы данных может обеспечить данных целостность и согласованность с помощью хранимых процедур.
- Делегирование прав доступа
- Во многих системах хранимым процедурам могут быть предоставлены права доступа к базе данных, которых непосредственно нет у пользователей, выполняющих эти процедуры.
- Некоторая защита от атак SQL-инъекций
- Хранимые процедуры можно использовать для защиты от атак путем внедрения. Параметры хранимой процедуры будут рассматриваться как данные, даже если злоумышленник вставит команды SQL. Кроме того, некоторые СУБД проверяют тип параметра. Однако хранимая процедура, которая, в свою очередь, генерирует динамический SQL с использованием входных данных, по-прежнему уязвима для SQL-инъекций, если не принять надлежащие меры предосторожности.
Другое использование [ править ]
В некоторых системах хранимые процедуры могут использоваться для управления управлением транзакциями; в других хранимые процедуры выполняются внутри транзакции, поэтому транзакции для них фактически прозрачны. Хранимые процедуры также можно вызывать из триггера базы данных или обработчика условий. Например, хранимая процедура может быть вызвана вставкой в определенную таблицу или обновлением определенного поля в таблице, и код внутри хранимой процедуры будет выполнен. Написание хранимых процедур в качестве обработчиков условий также позволяет администраторам баз данных более детально отслеживать ошибки в системе, используя хранимые процедуры для обнаружения ошибок и записи некоторой информации аудита в базу данных или внешний ресурс, например файл.
Сравнение с функциями [ править ]
- Функция — это подпрограмма, написанная для выполнения определенных вычислений.
- Скалярная функция возвращает только одно значение (или NULL), тогда как табличная функция возвращает (реляционную) таблицу, содержащую ноль или более строк, причем каждая строка содержит один или несколько столбцов.
- Функции должны возвращать значение (используя
RETURN
ключевое слово), но для хранимых процедур это не обязательно. - Хранимые процедуры могут использовать
RETURN
ключевое слово, но без передачи значения. - Функции могут использоваться в
SELECT
заявления, при условии, что они не манипулируют данными. Однако процедуры не могут быть включены вSELECT
заявления. - Хранимая процедура может возвращать несколько значений, используя
OUT
параметр или не возвращайте значение. - Хранимая процедура экономит время компиляции запроса.
- Хранимая процедура — это объект базы данных.
- Хранимая процедура — это материальный объект.
Сравнение с подготовленными заявлениями [ править ]
Подготовленные операторы берут обычный оператор или запрос и параметризуют его, чтобы в дальнейшем можно было использовать другие литеральные значения. Как и хранимые процедуры, они хранятся на сервере для повышения эффективности и обеспечивают некоторую защиту от атак SQL-инъекций. Хотя подготовленные операторы проще и более декларативны, они обычно не пишутся с использованием процедурной логики и не могут работать с переменными. Благодаря простому интерфейсу и реализации на стороне клиента подготовленные операторы более широко используются повторно между СУБД.
Сравнение со смарт-контрактами [ править ]
Смарт-контракт — это термин, применяемый к исполняемому коду, хранящемуся в блокчейне, а не в СУБД. Несмотря на то, что механизмы консенсуса результатов выполнения в общедоступных сетях блокчейнов принципиально отличаются от традиционных частных или федеративных баз данных, они выполняют якобы ту же функцию, что и хранимые процедуры, хотя обычно с ощущением значимости транзакции.
Недостатки [ править ]
- Языки хранимых процедур часто зависят от поставщика. Смена поставщиков баз данных обычно требует переписывания существующих хранимых процедур.
- Изменения в хранимых процедурах труднее отслеживать в системе контроля версий, чем в другом коде. Изменения должны быть воспроизведены в виде сценариев, которые будут сохранены в истории проекта и включены в них, а различия в процедурах может быть сложнее объединить и правильно отследить.
- Ошибки в хранимых процедурах не могут быть обнаружены на этапе компиляции или сборки в среде IDE приложения. То же самое происходит, если хранимая процедура пропала или была случайно удалена.
- Языки хранимых процедур разных производителей имеют разный уровень сложности.
- Поддержка инструментов для написания и отладки хранимых процедур часто не так хороша, как в других языках программирования, но это различается в зависимости от поставщика и языка.
- Например, и PL/SQL, и T-SQL имеют специальные IDE и отладчики. PL/PgSQL можно отлаживать из различных IDE.
Ссылки [ править ]
- ^ «Db2 12 – Прикладное программирование и SQL – Вызов хранимой процедуры из вашего приложения» . www.ibm.com . Проверено 26 мая 2022 г.
- ^ «Глава 11. Руководство по языку процедур SQL» . Документация OpenLink . Проверено 11 сентября 2019 г.
- ^ «Глава 42. Процедурные языки» . Документация PostgreSQL . 9 ноября 2023 г. Проверено 20 ноября 2023 г.