Читайте также:
|
Нередко случается, что элементарное с точки зрения пользователя действие по изменению данных в базе затрагивает сразу несколько таблиц. Например, удаление заказа с заданным номером вызывает удаление строк из двух таблиц: сначала из таблицы СодержимоеЗаказов (НомерЗаказа(FK), КодТовара(FK), Количество, Цена) удаляются все строки, относящихся к этому заказу, а потом удаляется одна строка из таблицы Заказы (НомерЗаказа(PK), Дата, КодПокупателя(FK)).
Другой пример: оператор регистрирует нового покупателя, а такой, возможно, уже существует в базе. Чтобы не было повторений, надо сначала проверить, есть ли покупатель с таким именем; если да, то далее ссылаться на него; если нет – то добавить новую строку в таблицу Покупатели (Код(PK), ФИО, Адрес).
Такую последовательность «многоэтажных» действий бывает удобно скрыть от пользователя, предоставив ему процедуру: задай входные параметры и вызови, а по выходным параметрам суди о результате. Это удобно и тем, что при изменении структуры таблиц (допустим, таблицу разбили на две) достаточно заменить тело процедуры, а входные и выходные параметры останутся прежними: для программы, вызывающей процедуру, ничего не изменится.
Процедуры, реализующие действия пользователя (бизнес-логику), можно писать на языке высокого уровня – приложение будет посылать СУБД последовательность простых SQL-команд: SELECT, INSERT, UPDATE, DELETE и пр. (такая технология называется «толстый клиент»). При изменении бизнес-логики придется переписывать пользовательское приложение, и «раздавать» пользователям новые экземпляры. А можно бизнес-логику написать на SQL – это будут хранимые процедуры, хранящиеся на сервере СУБД; пользовательская программы посылает на сервер SQL-команды вызова нужных процедур. При изменении алгоритма обработки данных процедуру переписывают на сервере один раз, а пользовательское приложение не меняется (если входные и выходные параметры процедуры те же). Вывод: везде, где можно, обработку данных оформлять в виде хранимых процедур.
К сожалению, хранимые процедуры реализованы не во всех СУБД (в MySQL до версии 4.х их нет).
Хранимая процедура – это процедура, написанная на языке SQL, имеющая имя, входные и выходные параметры, и выполняющая определенные действия с базой данных. Её тело хранится на сервере СУБД. Наиболее «продвинутые» СУБД, такие как Oracle, Microsoft SQL Server, автоматически оптимизируют скорость выполнения хранимых процедур, строя план выполнения. В теле хранимых процедур можно использовать конструкции «расширенного SQL»: IF–THEN–ELSE, циклы WHILE, FOR, объединять несколько инструкций в блоки BEGIN–END, объявлять локальные переменные, вызывать другие хранимые процедуры.
Хранимая процедура создается SQL-инструкцией CREATE PROCEDURE. В разных СУБД её синтаксис может отличаться.
MySQL 3.x хранимые процедуры не поддерживает.
В Firebird/Interbase процедура создается инструкцией:
CREATE PROCEDURE ИмяПроцедуры
(ИмяПараметра1 ТИП, ИмяПараметра2 ТИП, и т.д.) /*входные параметры*/
Дата добавления: 2015-09-11; просмотров: 69 | Поможем написать вашу работу | Нарушение авторских прав |
| <== предыдущая лекция | | | следующая лекция ==> |
| ТЕОРЕТИЧЕСКАЯ ЧАСТЬ | | | Триггеры |