Глобальные временные процедуры разрешается исполнять в любом соединении. Подобно временным процедурам других типов, они создаются в базе данных 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
Триггеры являются одной из разновидностей хранимых процедур. Их исполнение происходит при выполнении для таблицы какого-либо оператора языка манипулирования данными (DML). Триггеры используются для проверки целостности данных, а также для отката транзакций.
Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри реляционной базы данных. Применение триггеров большей частью весьма удобно для пользователей базы данных. И все же их использование часто связано с дополнительными затратами ресурсов на операции ввода/вывода. В том случае, когда тех же результатов (с гораздо меньшими непроизводительными затратами ресурсов) можно добиться с помощью хранимых процедур или прикладных программ, применение триггеров нецелесообразно.
Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных в базе данных. С помощью ограничений целостности, правил и значений по умолчанию не всегда можно добиться нужного уровня функциональности. Часто требуется реализовать сложные алгоритмы проверки данных, гарантирующие их достоверность и реальность. Кроме того, иногда необходимо отслеживать изменения значений таблицы, чтобы нужным образом изменить связанные данные. Триггеры можно рассматривать как своего рода фильтры, вступающие в действие после выполнения всех операций в соответствии с правилами, стандартными значениями и т.д.
Триггер представляет собой специальный тип хранимых процедур, запускаемых сервером автоматически при попытке изменения данных в таблицах, с которыми триггеры связаны. Каждый триггер привязывается к конкретной таблице. Все производимые им модификации данных рассматриваются как одна транзакция. В случае обнаружения ошибки или нарушения целостности данных происходит откат этой транзакции. Тем самым внесение изменений запрещается. Отменяются также все изменения, уже сделанные триггером.
Создает триггер только владелец базы данных. Это ограничение позволяет избежать случайного изменения структуры таблиц, способов связи с ними других объектов и т.п.
Триггер представляет собой весьма полезное и в то же время опасное средство. Так, при неправильной логике его работы можно легко уничтожить целую базу данных, поэтому триггеры необходимо очень тщательно отлаживать.
В отличие от обычной подпрограммы, триггер выполняется неявно в каждом случае возникновения триггерного события, к тому же он не имеет аргументов. Приведение его в действие иногда называют запуском триггера. С помощью триггеров достигаются следующие цели:
проверка корректности введенных данных и выполнение сложных ограничений целостности данных, которые трудно, если вообще возможно, поддерживать с помощью ограничений целостности, установленных для таблицы;
выдача предупреждений, напоминающих о необходимости выполнения некоторых действий при обновлении таблицы, реализованном определенным образом;
накопление аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили;
поддержка репликации.
При условии правильного использования триггеры могут стать очень мощным механизмом. Основное их преимущество заключается в том, что стандартные функции сохраняются внутри базы данных и согласованно активизируются при каждом ее обновлении. Это может существенно упростить приложения. Тем не менее следует упомянуть и о присущих триггеру недостатках:
сложность: при перемещении некоторых функций в базу данных усложняются задачи ее проектирования, реализации и администрирования;
скрытая функциональность: перенос части функций в базу данных и сохранение их в виде одного или нескольких триггеров иногда приводит к сокрытию от пользователя некоторых функциональных возможностей. Хотя это в определенной степени упрощает его работу, но, к сожалению, может стать причиной незапланированных, потенциально нежелательных и вредных побочных эффектов, поскольку в этом случае пользователь не в состоянии контролировать все процессы, происходящие в базе данных;
влияние на производительность: перед выполнением каждой команды по изменению состояния базы данных СУБД должна проверить триггерное условие с целью выяснения необходимости запуска триггера для этой команды. Выполнение подобных вычислений сказывается на общей производительности СУБД, а в моменты пиковой нагрузки ее снижение может стать особенно заметным. Очевидно, что при возрастании количества триггеров увеличиваются и накладные расходы, связанные с такими операциями.
Неправильно написанные триггеры могут привести к серьезным проблемам, таким, например, как появление "мертвых" блокировок. Триггеры способны длительное время блокировать множество ресурсов, поэтому следует обратить особое внимание на сведение к минимуму конфликтов доступа.
В нашей работе триггеры не были использованы ввиду отсутствия необходимости в них.
4.3 Описание типов блокировок
Блокировка — это объект, с помощью которого программы показывают зависимость пользователя от ресурса. Программы запрещают другим пользователям выполнять над ресурсами операции, которые негативно влияют на зависимость пользователя, владеющего блокировкой, от этого ресурса. Блокировки управляются внутрисистемными механизмами, они устанавливаются и снимаются в зависимости от действий пользователя.
С помощью блокировок SQL Server 2000 реализует пессимистическое управление параллельным выполнением при работе множества пользователей, одновременно модифицирующих БД. По умолчанию SQL Server управляет транзакциями и блокировками для каждого соединения отдельно. Например, если приложение открывает два соединения с
SQL Server, то блокировка, установленная одним соединением, не может быть использована другим. Ни одному из соединений не удастся установить блокировку, конфликтующую с блокировками, удерживаемыми другими соединениями. Это правило не действует лишь на связанные соединения.
Блокировки применяются в БД на разных уровнях. Их устанавливают для строк, страниц, ключей, диапазонов ключей, индексов, таблиц или баз данных. SQL Server динамически определяет уровень блокировки для каждого оператора Transact-SQL. Уровень, на котором задается блокировка, может варьироваться для разных объектов в пределах одного запроса. Например, в одной очень маленькой таблице блокировка устанавливается на уровне таблицы, тогда как в другой, большей таблице она задается для отдельных строк.
Пользователям не нужно определять уровень блокировки, администраторы также не.должны заниматься его настройкой. Каждый экземпляр SQL Server гарантирует, что блокировки, действующие на одном уровне, не нарушат блокировок, установленных на другом уровне.
Существуют несколько видов блокировок: разделяемые, обновления, монопольные, предварительные и блокировки схемы. Вид блокировки показывает уровень зависимости соединения от заблокированного объекта. SQL Server контролирует взаимодействие блокировок разных видов. Например, не удастся установить монопольную блокировку ресурса, если другие соединения удерживают для него разделяемые блокировки.