MySQL: руководство профессионала

Для мультитабличного обновляемого view, INSERT может работать, если это вставляет в одиночную таблицу. DELETE не обеспечивается вообще.

Предложение WITH CHECK OPTION может быть дано для обновляемого view, чтобы предотвратить вставки или модификации в строки за исключением тех, для которых предложение WHERE в select_statement истинно.

В предложении WITH CHECK OPTION для обновляемого view ключевые слова LOCAL и CASCADED определяют контекст тестирования проверки, когда view определен в терминах другого view. Ключевое слово ограничивает LOCAL CHECK OPTION только определяемым view. CASCADED задает проверку для основных view, которые также будут оценены. Когда никакое ключевое слово не дано, значение по умолчанию: CASCADED. Рассмотрите определения для следующей таблицы и набора view:

mysql> CREATE TABLE t1 (a INT);

mysql> CREATE VIEW v1 AS SELECT * FROM t1 WHERE a < 2

– > WITH CHECK OPTION;

mysql> CREATE VIEW v2 AS SELECT * FROM v1 WHERE a > 0

– > WITH LOCAL CHECK OPTION;

mysql> CREATE VIEW v3 AS SELECT * FROM v1 WHERE a > 0

– > WITH CASCADED CHECK OPTION;

Здесь view v2 и v3 определены в терминах другого view, а именно v1. v2 имеет опцию проверки LOCAL, так что вставки проверены только для v2. v3 имеет опцию проверки CASCADED, так что вставки проверены не только по собственной проверки, но и для таковых основных view. Следующие инструкции иллюстрируют эти различия:

mysql> INSERT INTO v2 VALUES (2);

Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO v3 VALUES (2);

ERROR 1369 (HY000): CHECK OPTION failed 'test.v3'

На обновляемость view можно воздействовать значением переменной системы updatable_views_with_limit. Команда CREATE VIEW была добавлена в MySQL 5.0.1. WITH CHECK OPTION было выполнено в MySQL 5.0.2.

7.3. Синтаксис DROP VIEW

DROP VIEW [IF EXISTS]

view_name [, view_name] …

[RESTRICT | CASCADE]

DROP VIEW удаляет один или большее количество view. Вы должны иметь привилегию DROP для каждого view. Если любой из view, именованных в списке параметров не существует, MySQL возвращает индикацию ошибки с именем, которые не существует, но удаляет все view в списке, которые существуют.

Предложение IF EXISTS предотвращает ошибку для просмотров, которые не существуют. Когда это предложение дано, NOTE будет сгенерировано для каждого несуществующего view.

RESTRICT и CASCADE, если заданы, анализируются и игнорируются. Эта инструкция была добавлена в MySQL 5.0.1.

7.4. MySQL 5.1 FAQ Views

7.4.1: Имеется ли форум для обсуждения MySQL Views?

Да. http://forums.mysql.com/list.php?100

7.4.2: Что случается с view, если основная таблица удалена или переименована?

После создания view, возможно удалить или изменить таблицу (или view), к которому обращается определение. Чтобы проверять определение view для выявления проблем этого вида, используйте инструкцию CHECK TABLE.

7.4.3: MySQL 5.1 имеет кадры таблицы?

Нет.

7.4.4: MySQL 5.1 имеет осуществленные views?

Нет.

7.4.5: Можно ли вставлять во views, которые основаны на объединениях?

Это возможно, если Ваша инструкция INSERT имеет список столбцов, который прояснит, что имеется только одна включаемая таблица. Вы не можете вставлять в много таблиц одиночной вставкой на view.

Глава 8. Планировщик событий

Эта глава описывает планировщик событий MySQL, поддержка которого была добавлена в MySQL 5.1.6.

8.1. Обзор планировщика событий

События MySQL представляют собой задачи, которые выполняются согласно плану. Следовательно, мы иногда обращаемся к ним как к планируемым событиям. Когда Вы создаете событие, Вы создаете именованный объект базы данных, содержащий одну или большее количество инструкций SQL, которые будут выполнены в одном или более регулярных интервалах, начиная и заканчивая в специфическую дату и время. Концептуально, это подобно идее Unix crontab (также известно как cron job) или Windows Task Scheduler.

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

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

События MySQL имеют следующие главные свойства и реквизиты:

В MySQL 5.1.12 и позже событие уникально идентифицировано именем и схемой, к которой оно назначено. Ранее событие было также уникально для definer.

Событие выполняет специфическое действие согласно плану. Это действие состоит из инструкции SQL, которая может быть составной. Синхронизация события может быть одноразовая или текущая. Одноразовое событие выполняется только один раз. Текущее событие повторяет действие в регулярном интервале, и план для события может быть назначено специфическое начало (день и время), конечный день и время, оба момента или ни один из них. По умолчанию событие начинается, как только создано, и продолжается неопределенно, пока оно не будет заблокировано или удалено.

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

Многие из реквизитов события могут быть установлены или изменяться, используя инструкции SQL. Эти реквизиты включают имя события, синхронизацию, постоянство (то есть, сохраняется ли событие после окончания плана), состояние (включено или заблокировано), действие, которое нужно выполнить, и схема, к которой событие назначено.

definer события представляет собой пользователя, который создал событие, если событие не было изменено, тогда definer становится пользователь, который выдал последнюю инструкцию ALTER EVENT, производящую это событие. Событие может изменяться любым пользователем, имеющим привилегию EVENT на базе данных, для которой событие определено. До MySQL 5.1.12 только definer события или пользователь, имеющий привилегии на таблице mysql.event, мог изменять данное событие.