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

• Во-первых, для этих целей используются процедуры базы данных, к которым возможно указать права доступа и использования.

• Триггеры — это само запускающиеся процедуры, срабатывающие при 3-х действиях базы данных: Insert, Delete, Update.

• Событияв базе данных. В БД могут быть зафиксированы события, такие как при возникновении каких-то ошибок (стандартная функция, которая есть в SQL Server – это rise error,ее можно встроить, и она будет генерировать ошибку). Могут быть сделаны более сложные события. К примеру, есть склад комплектующих, и каких-то комплектующих стало меньше заранее оговоренного уровня, то система может послать вам сообщение, что пора подымать «задницу», чтобы сделать очередную поставку.

Процедуры

Здесь единственное отличие – это то, что оформление процедуры или функции делается на языке SQL. Как правило, они хранятся в системных таблицах базы данных, т.е. в виде текста, а в некоторых СУБД они могут храниться уже скомпилированном виде. Однако чаще всего – не скомпилированный код, потому как такие процедуры работают с данными, которые имеют свойство быть непостоянными как по величине, так и по содержанию. Поэтому перед тем как сделать какую-то выборку процедура натыкается на такую программу как оптимизатор, которая при большой базе данных должна создать план запроса наиболее быстрого считывания, вот поэтому их не компилируют, т.к. нужен план запроса, их компилируют уже потом. Данные же, если эта операционная база данных, то там они по количеству записей, по объему, по числам меняться. В случае архивной СУБД, к примеру, библиотеки, то там можно и скомпилированный вариант, поскольку все более или менее постоянно. Но чаще все процедуры интерпретируются интерпретатором базы данных и выполняются.

Как уже было сказано, в современных СУБД есть кэш процедур, куда они могут загрузиться в скомпилированном виде в кэш, и могут быть там пока по времени запуска не будут вытесненными другими более новыми процедурами.

Использование процедур преследует 4 основные цели:
1. Обеспечивается новый независимый уровень централизованного контроля за базами данных, естественно, со стороны администратора. Поскольку он может устанавливать права на запуск процедур.
2. Одна подпрограмма или одна процедура может запускаться несколькими прикладными программами, т.е. несколькими клиентами. Таким образом сокращается время написания программ, т.к. процедуры находятся не у клиента, а на сервере, не требуется переделка клиентских приложений. Все делается на сервер базы данных, а клиентское приложение не меняется – это очень удобно.
3. Использование процедур существенно меняет трафик в сети, поскольку от клиента по сети к серверу идет вызов процедуры, а это имя, которое может быть сколь угодно коротким, возможно с параметрами. Все равно это меньше, чем вызов запроса.
4. Процедуры вместе с правилами позволяют администратору лучше поддерживать целостность базы данных, чтобы данные в главной и подчиненной таблицах были синхронны по ключам.

Триггеры

Триггеры позволяют организовать автоматическую обработку таких событий как добавить, удалить, обновить запись, когда в каких-то других подчиненных таблицах предполагается сделать еще что-то. К примеру, если удалить, то каскадно удалить еще подчиненные записи. Если обновить ключ, то в дочерней таблице изменить ключ на новый. Можно, наоборот, не изменять — это может от стратегии зависеть. Могут быть выполнены какие-то дополнительные действия: посылаться какие-нибудь e-mail или и т.п. Т.е. вообще говоря, может быть запущен автоматически целый комплекс программ, который выполняется в случае выполнения тех или иных действий.

В процессе выполнения триггеров автоматически создаются т.н. триггерные таблицы, где хранятся изменяемые данные. Например, при добавлении в таблицу, то это триггерная таблица на вставку (это запись с новыми значениями). При обновлении – со старыми и новыми значениями, при удалении – только со старыми. К этим триггерным таблицам в теле триггера можно иметь доступ. Триггерные таблицы обычно имеют специфические названия, например, в SQL Server они называются deleted и inserted, в ORCALE они называются new и old. Доступ – <имя таблицы>.<имя поля>.

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

Тут надо отметить историческую справедливость, что фирма Sybase первая предложила использование триггеров. Несмотря на то, что триггеры имеют большую гибкость и могут содержать достаточно большие строчки кода, им присущ определенный недостаток. Во-первых, усложнение базы данных. Они хранятся на сервере, чем больше триггеров, тем больше объектно-системных таблиц. Далее, скрытие логики от пользователя: когда база данных разрабатывается первоначально «тут еще куда не шло», но когда начинается модернизация базы данных, и часто приглашаются другие программисты, понять логику работы триггеров достаточно тяжело. Потому как просто так запустить их нельзя (они запускаются специфическим образом) и их логику очень трудно понять. Кроме того, они неадекватно (или по-разному) влияют на производительность, поэтому оценить производительность в такой системе бывает достаточно трудно.

События

События позволяют фактически делать оповещение, точнее говоря, сервер базы данных оповещает другие программы о наступлении каких-то событий. Как правило, такое событие создается командой CreateDBEvent – создать событие, а потом его надо инициировать, для этого используется оператор типа rise DBEvent.

Комментарии запрещены.