Преимущества хранимых процедур

Обработка ошибок

Циклическая обработка наборов записей

Одной из самых распространенных ситуаций, в которых требуется циклическое выполнение определенных действий, является построчная обработка набора записей, возвращенного некоторым запросом. Во всех основных диалектах SPL для этого предусмотрены специальные конструкции. Концептуально они подобны встраиваемым в клиентские приложения инструкциям DECLARE CURSOR, OPEN, FETCH И CLOSE встроенного SQL или соответствующим вызовам API-функций Однако результат запроса в данном случае направляется не приложению, а хранимой процедуре, которая выполняется самой СУБД. Соответственно, результирующие данные оказываются не в переменных клиентского приложения, а в локальных переменных хранимой процедуры.

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

В Transact-SQL информацию о произошедших ошибках можно получить из специальных системных переменных. Имеется огромное количество глобальных системных переменных, хранящих информацию о состоянии сервера и транзакции, открытых подключениях и т.п. Однако для обработки ошибок чаще всего используются только две из них: @@error — код ошибки, произошедшей при выполнении последней инструкции SQL;

@@sqlstatus — состояние последней операции FETCH.

Признаком "нормального завершения" в обеих переменных является значение 0. Другие значения указывают на ошибки или нестандартные ситуации. В хранимых процедурах Transact-SQL глобальные переменные используются точно так же, как локальные. В частности, их можно применять в условиях циклов и в инструкции if.

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

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

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

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

Защита. В большинстве СУБД хранимые процедуры считаются защищаемыми объектами и им назначаются отдельные привилегии. Пользователь, вызывающий хранимую процедуру, должен иметь право на ее выполнение, но не обязательно — права на доступ к таблицам, с которыми она работает (просматривает или модифицирует). Таким образом, администратор базы данных получает более широкие возможности в плане защиты данных и управления доступом пользователей к объектам базы данных.

Инкапсуляция. Идея хранимых процедур хорошо соответствует одной из главных целей объектно-ориентированного программирования (ООП) — инкапсуляции данных и кода в защищенные структуры, доступные только посредством использования ограниченного и строго определенного набора интерфейсов. По терминологии ООП, хранимые процедуры можно назвать методами, посредством которых пользователи или внешние программы могут манипулировать объектами СУБД. Если вы хотите строго придерживаться объектно-ориентированного подхода, нужно с помощью системы защиты СУБД полностью запретить непосредственный доступ к данным через SQL и оставить для доступа к базе данных только хранимые процедуры. Однако столь суровые ограничения мало кем практикуются (если вообще практикуются хоть кем-то).

Дата добавления: 2015-06-25