Навигация
4.2.2 Хранимые процедуры
Хранимые процедуры позволяют повысить производительность, расширяют возможности программирования и поддерживают функции безопасности, недоступные при использовании команд Transact-SQL, отсылаемых для обработки на сервер. Повышается производительность — за счет локального (по отношению к базе данных) хранения, перекомпиляции исходного текста и кэширования Возможности программирования расширяются благодаря применению таких распространенных средств программирования, как использование входных и выходных параметров, а также благодаря многократному использованию процедур. Функции безопасности подразумевают шифрование текста процедуры и ограничение привилегий. В результате пользователи получают ограниченный доступ к внутренней структуре базы данных, однако им разрешено запускать хранимые процедуры, выполняющие различные действия над базой данных.
При пересылке каждой команды (или пакета команд) Transact-SQL на сервер для обработки последний должен определить, есть ли у отправителя права на исполнение этих команд и допустимы ли сами команды. Проверив права доступа и синтаксис команд, SQL Server строит план исполнения запроса. Хранимые процедуры в данном случае более эффективны. При создании они сохраняются в SQL Server, поэтому при вызове хранимой процедуры ее содержимое сразу же обрабатывается сервером. Один - единственный оператор позволяет вызвать сложный сценарий Transact-SQL, который содержится в хранимой процедуре, что позволяет избежать пересылки через сеть сотен команд.
Перед созданием хранимой процедуры ее команды проходят синтаксическую проверку. Если при этом не обнаружено ни одной ошибки, имя процедуры сохраняется в таблице SysObjects, а ее текст — в таблице SysComments. При первом запуске хранимой процедуры создается план исполнения и хранимая процедура компилируется. В дальнейшем ее обработка осуществляется быстрее, поскольку SQL Server не приходится проверять синтаксис команд, создавать план исполнения и компилировать текст процедуры. До создания нового плана в кэше проверяется наличие существующего плана исполнения.
Относительный прирост производительности, вызываемый размещением планов исполнения хранимых процедур в кэше процедур, уменьшается, поскольку планы исполнения всех операторов SQL теперь хранятся в кэше процедур. При исполнении оператора Transact-SQL по возможности предпринимается попытка использования существующего плана исполнения.
Созданную хранимую процедуру можно вызвать в любой момент, при возникновении малейшей необходимости. Это обеспечивает модульность и стимулирует повторное использование кода. Последнее облегчает сопровождение базы данных, так как она изолирована от меняющихся бизнес-правил. Модифицировать хранимую процедуру в соответствии с новыми правилами можно в любой момент. После этого все приложения, использующие ее, автоматически придут в соответствие с новыми бизнес-правилами без непосредственной модификации.
Подобно программам, написанным на других языках программирования, хранимые процедуры способны принимать входные параметры, возвращать значения выходных параметров, поддерживать обратную связь с пользователем посредством вывода кодов состояния и текстовых сообщений, а также вызывать другие процедуры. Например, одна хранимая процедура может возвращать другой код состояния, в зависимости от которого последняя выполняет те или иные действия.
Если разработчикам удобно писать сложные программы на таких языках, как C++, то затем эти программы можно вызывать из SQL Server средствами хранимых процедур особого типа, которые называются расширенными хранимыми процедурами.
Хранимую процедуру пишут для решения какой-либо одной задачи — в результате ее можно использовать в нескольких базах данных. Например, хранимая процедура sp_rename предназначена для изменения имен созданных пользователем объектов (например, таблицы, поля или пользовательского типа данных) в текущей базе данных. В одной базе данных ее используют для переименования таблицы, в другой — столбца таблицы и т. д.
Другое важное назначение хранимых процедур — повышение безопасности посредством изоляции и шифрования. Пользователям можно предоставить право на исполнение хранимой процедуры без непосредственного доступа к объектам базы данных, с которыми работает хранимая процедура. Кроме того, если хранимую процедуру зашифровать при создании или модификации, пользователям не удастся прочитать команды Transact-SQL, составляющие процедуру. Эти функции безопасности позволяют изолировать от пользователя структуру базы данных, что обеспечивает целостность данных и надежность базы.
Существует пять классов хранимых процедур: системные, локальные, временные, расширенные и удаленные. Есть и другие способы классификации, но этот позволяет легко описать местонахождение, назначение и возможности хранимой процедуры.
Системные хранимые процедуры находятся в базе данных Master. Как правило, их имена начинаются с префикса sp_. Они предназначены для поддержки функций SQL Server (в частности, процедур для работы с каталогом). К ним относится выборка данных из системных таблиц внешними приложениями, администрирование базы данных и управление безопасностью.
Локальные хранимые процедуры обычно находятся в пользовательской базе данных. Как правило, их создают для решения определенных задач в конкретной базе данных. Локальные хранимые процедуры также позволяют настраивать системные хранимые процедуры.
Чтобы создать на основе системной хранимой процедуры пользовательскую процедуру, нужно сделать копию системной хранимой процедуры, а затем сохранить ее как локальную хранимую процедуру.
Временная хранимая процедура похожа на локальную, однако она существует лишь до закрытия соединения, в котором создана, или до завершения работы SQL Server. В зависимости от типа такая процедура удаляется после завершения работы сервера или разрыва соединения. Непостоянство обусловлено тем, что временные хранимые процедуры находятся в базе данных TempDB. При каждом запуске сервера эта база создается заново, поэтому после закрытия сервера все объекты этой базы данных исчезают. Временные хранимые процедуры полезны при работе с более ранними версиями SQL Server, которые не поддерживают повторное использование планов исполнения, а также в тех случаях, когда нет смысла сохранять процедуру, поскольку значения ее параметров постоянно меняются.
Существует три типа временных хранимых процедур: локальные (или закрытые), глобальные и создаваемые непосредственно в TempDB. Локальная процедура всегда начинается с символа #, а глобальная — с ##. При исполнении временной хранимой процедуры ее область действия ограничена соединением, в котором она создана. Однако такая процедура видима всем пользователям, установившим соединение с базой данных, в окне Object Browser в Query Analyzer. Ограниченность области ее действия исключает возникновение конфликтов имен с другими соединениями, в которых созданы временные хранимые процедуры. Чтобы гарантировать уникальность имени временной хранимой процедуры, SQL Server добавляет к нему набор символов подчеркивания и уникальный номер соединения. Привилегии для локальной процедуры не предоставляются другим пользователям. Временная хранимая процедура удаляется из TempDB при закрытии соединения, в котором она создана.
Глобальные временные процедуры разрешается исполнять в любом соединении. Подобно временным процедурам других типов, они создаются в базе данных TempDB, поэтому у них должны быть уникальные имена. Право на исполнение глобальной временной процедуры автоматически предоставляется роли public и не может быть изменено.
Глобальные временные процедуры так же непостоянны, как и локальные. Они удаляются после закрытия соединения, в котором созданы.
Временные хранимые процедуры, которые создаются непосредственно в TempDB. отличаются от локальных и глобальных процедур следующим:
• для них разрешается настроить права доступа;
• они сохраняются даже после завершения соединения, в котором созданы;
• они не удаляются до завершения работы SQL Server.
Поскольку процедуры этого типа создаются непосредственнов TempDB, важно полностью определять имя объекта базы данных в коде Transact-SQL.
Расширенные хранимые процедуры обращаются к внешним программам, скомпилированным в виде 32-разрядных DLL. Некоторые системные хранимые процедуры также рассматриваются как расширенные. Соглашение об именовании предполагает использование в именах расширенных хранимых процедур префикса хр_. Однако имена некоторых расширенных процедур начинаются с префикса sp_, а в именах некоторых других, не расширенных процедур используется префикс хр_. Поэтому нельзя различить системные и расширенные хранимые процедуры, полагаясь лишь на отличия в именах.
Определить, является ли хранимая процедура расширенной, позволяет функция ОВ-JECTPROPERTY. Она возвращает для свойства IsExtendedProc значение 1, если процедура является расширенной, или 0, если процедура таковой не является.
Как следует из названия, удаленная хранимая процедура работает на удаленной копии SQL Server. Удаленные хранимые процедуры оставлены для совместимости с предыдущими версиями, в SQL Server 2000 их заменили распределенные запросы.
В наше БД были созданы хранимых процедуры. Ниже представлен перечень и краткая характеристика хранимых процедур, которые были использованы в наше базе данных.
Процедуры удаления данных:
set ANSI_NULLS OFF
set QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[AgentDelete]
@Kod_Agent int
AS
Delete from Agent
where
Kod_Agent=@Kod_Agent
Процедуры добавления данных:
set ANSI_NULLS OFF
set QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[AgentEdit]
@Kod_Agent int,
@Naimen_Agent varchar(25),
@Kont_lico varchar(20),
@Adres varchar(25),
@Tel varchar (25),
@Schet varchar (25)
AS
Update Agent SET
Naimen_Agent = @Naimen_Agent,
Kont_lico = @Kont_lico,
Adres = @Adres,
Tel = @Tel,
Schet = @Schet
where
Kod_Agent=@Kod_Agent
Процедуры обновления данных:
set ANSI_NULLS OFF
set QUOTED_IDENTIFIER OFF
GO
ALTER PROCEDURE [dbo].[UpdPrihKol]
AS
update Nomenkl
set prihod = p.kolich
from (select kod_nomen, sum(kolich) as kolich
from Prihod
group by kod_nomen) as p
inner join nomenkl n on p.kod_nomen=n.Kod_nomen
Update Nomenkl
set
Ostatok=Prihod-Rashod
Похожие работы
... БД). Логическая модель данных представлена в виде ER-диаграмы на рис. 2.2. Рис 2.2 ER-диаграмма модели данных АСИС “Учет поставок” 3. Проектирование алгоритмов справочно-информационной системы учета и контроля поставок на предприятие. Алгоритмизация в самом общем виде может быть определена как процесс направленного действия проектировщика (группы ...
... ; - контроль соответствия фактических и плановых данных об объеме производства; - анализ отклонений фактических данных от установленных плановых показателей. 3. Автоматизированная система учета производственного процесса металлоцентра 3.1 Программно-технические средства общего назначения Основным программным обеспечением всех, без исключений, компьютеров ИС является операционная ...
0 комментариев