Эта статья является обзором представлений, появившихся в MySQL версии 5.0. В ней рассмотрены вопросы создания, преимущества и ограничения представлений.
Что такое представление?
Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.
Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.
Представления могут основываться как на таблицах, так и на других представлениях, т.е. могут быть вложенными (до 32 уровней вложенности).
Преимущества использования представлений:
- Дает возможность гибкой настройки прав доступа к данным за счет того, что права даются не на таблицу, а на представление. Это очень удобно в случае если пользователю нужно дать права на отдельные строки таблицы или возможность получения не самих данных, а результата каких-то действий над ними.
- Позволяет разделить логику хранения данных и программного обеспечения. Можно менять структуру данных, не затрагивая программный код, нужно лишь создать представления, аналогичные таблицам, к которым раньше обращались приложения. Это очень удобно когда нет возможности изменить программный код или к одной базе данных обращаются несколько приложений с различными требованиями к структуре данных.
- Удобство в использовании за счет автоматического выполнения таких действий как доступ к определенной части строк и/или столбцов, получение данных из нескольких таблиц и их преобразование с помощью различных функций.
Ограничения представлений в MySQL
В статье приведены ограничения для версии MySQL 5.1 (в дальнейшем их число может сократиться).
- нельзя повесить триггер на представление,
- нельзя сделать представление на основе временных таблиц; нельзя сделать временное представление;
- в определении представления нельзя использовать подзапрос в части FROM,
- в определении представления нельзя использовать системные и пользовательские переменные; внутри хранимых процедур нельзя в определении представления использовать локальные переменные или параметры процедуры,
- в определении представления нельзя использовать параметры подготовленных выражений (PREPARE),
- таблицы и представления, присутствующие в определении представления должны существовать.
- только представления, удовлетворяющие ряду требований, допускают запросы типа UPDATE, DELETE и INSERT.
Создание представлений
Для создания представления используется оператор CREATE VIEW, имеющий следующий синтаксис:
view_name — имя создаваемого представления. select_statement — оператор SELECT, выбирающий данные из таблиц и/или других представлений, которые будут содержаться в представлении
Оператор CREATE VIEW содержит 4 необязательные конструкции:
- OR REPLACE — при использовании данной конструкции в случае существования представления с таким именем старое будет удалено, а новое создано. В противном случае возникнет ошибка, информирующая о сществовании представления с таким именем и новое представление создано не будет. Следует отметить одну особенность — имена таблиц и представлений в рамках одной базы данных должны быть уникальны, т.е. нельзя создать представление с именем уже существующей таблицы. Однако конструкция OR REPLACE действует только на представления и замещать таблицу не будет.
- ALGORITM — определяет алгоритм, используемый при обращении к представлению (подробнее речь об этом пойдет ниже).
- column_list — задает имена полей представления.
- WITH CHECK OPTION — при использовании данной конструкции все добавляемые или изменяемые строки будут проверяться на соответствие определению представления. В случае несоответствия данное изменение не будет выполнено. Обратите внимание, что при указании данной конструкции для необновляемого представления возникнет ошибка и представление не будет создано. (подробнее речь об этом пойдет ниже).
По умолчанию колонки представления имеют те же имена, что и поля возращаемые оператором SELECT в определении представления. При явном указании имен полей представления column_list должен включать по одному имени для каждого поля разделенных запятой. Существует две причины по которым желательно использовать явное указание имен полей представления:
1. Имена полей представления должны быть уникальны в пределах данного представления. При создании представления основанного на нескольких таблицах возможна ситуация повторения имен полей представления. Например:
Для избежания такой ситуации нужно явно указывать имена полей представления
Того же результата можно добиться, используя синонимы (алиасы) для названий колонок:
2. В случае если в определении представления получаемые данные преобразуются с помощью каких-то функций, то именем поля будет данное выражение, что не очень удобно для дальнейших ссылок на это поле. Напимер:
Вряд ли удобно использовать в дальнейшем в качестве имени поля `group_concat(DISTINCT username ORDER BY username separator ‘+’)`
Для просмотра содержимого представления мы используем оператор SELECT (полностью аналогично как в случае простой таблицы), с другой строны, оператор SELECT есть в самом определении представления, т.е. получается вложенная конструкция — запрос в запросе. При этом, некоторые конструкции оператора SELECT могут присутствовать в обоих операторах. Возможны три варианта развития событий: они обе будут выполнены, одна из них будет проигнорированна и результат неопределен. Рассмотрим подробнее эти случаи:
- Если в обоих операторах встречается условие WHERE, то оба этих условия будут выполнены как если бы они были объединены оператором AND.
- Если в определении представления есть конструкция ORDER BY, то она будет работать только в случае отсутствия во внешнем операторе SELECT, обращающемся к представлению, собственного условия сортировки. При наличии конструкции ORDER BY во внешнем операторе сортировка, имеющаяся в определении представления, будет проигнорирована.
- При наличии в обоих операторах модификаторов, влияющих на механизм блокировки, таких как HIGH_PRIORITY, результат их совместного действия неопределен. Для избежания неопределенности рекомендуется в определении представления не использовать подобные модификаторы.
Алгоритмы представлений
Существует два алгоритма, используемых MySQL при обращении к представлению: MERGE и TEMPTABLE.
В случае алгоритма MERGE, MySQL при обращении к представлению добавляет в использующийся оператор соответствующие части из определения представления и выполняет получившийся оператор.
В случае алгоритма TEMPTABLE, MySQL заносит содержимое представления во временную таблицу, над которой затем выполняется оператор обращенный к представлению.
Обратите внимание: в случае использования этого алгоритма представление не может быть обновляемым (см. далее).
При создании представления есть возможность явно указать используемый алгоритм с помощью необязательной конструкции [ALGORITHM =
UNDEFINED означает, что MySQL сам выбирает какой алгоритм использовать при обращении к представлению. Это значение по умолчанию, если данная конструкция отсутствует.
Использование алгоритма MERGE требует соответствия 1 к 1 между строками таблицы и основанного на ней представления.
Пусть наше представление выбирает отношение числа просмотров к числу ответов для тем форума:
Для данного представления каждая строка соответствует единственной строке из таблицы topics, т.е. может быть использован алгоритм MERGE. Рассмотрим следующее обращение к нашему представлению:
В случае MERGE алгоритма MySQL включает определение представления в использующийся оператор SELECT: заменяет имя представления на имя таблицы, заменяет список полей на определения полей представления и добавляет условие в части WHERE с помощью оператора AND. Итоговый оператор, выполняемый затем MySQL, выглядит следующим образом:
Если в определении представления используются групповые функции (count, max, avg, group_concat и т.д.), подзапросы в части перечисления полей или конструкции DISTINCT, GROUP BY, то не выполняется требуемое алгоритмом MERGE соответствие 1 к 1 между строками таблицы и основанного на ней представления.
Пусть наше представление выбирает количество тем для каждого форума:
Найдем максимальное количество тем в форуме:
Если бы использовался алгоритм MERGE, то этот запрос был бы преобразован следующим образом:
Выполнение этого запроса приводит к ошибке "ERROR 1111 (HY000): Invalid USE of GROUP function", так как используется вложенность групповых функций.
В этом случае MySQL использует алгоритм TEMPTABLE, т.е. заносит содержимое представления во временную таблицу (данный процесс иногда называют "материализацией представления"), а затем вычисляет MAX() используя данные временной таблицы:
Подводя итог, следует отметить, что нет серьезных причин явно указывать алгоритм при создании представления, так как:
- В случае UNDEFINED MySQL пытается использовать MERGE везде где это возможно, так как он более эффективен чем TEMPTABLE и, в отличие от него, не делает представление не обновляемым.
- Если вы явно указываете MERGE, а определение представления содержит конструкции запрещающие его использование, то MySQL выдаст предупреждение и установит значение UNDEFIND.
Представление называется обновляемым, если к нему могут быть применимы операторы UPDATE и DELETE для изменения данных в таблицах, на которых основано представление. Для того, чтобы представление было обновляемым должно быть выполнено 2 условия:
- Соответствие 1 к 1 между строками представления и таблиц, на которых основано представление, т.е. каждой строке представления должно соответствовать по одной строке в таблицах-источниках.
- Поля представления должны быть простым перечислением полей таблиц, а не выражениеями col1/col2 или col1+2.
Обратите внимание: встречающиеся в русско-язычной литературе требования, чтобы обновляемое представление было основано на единственной таблице и присутствие в числе полей представления первичного ключа физичекой таблицы не являются необходимыми. Скорее всего требование единственной таблицы является ошибкой перевода. Дело в том, что через представление, основанное на нескольких таблицах, может обновлять только одну таблицу за запрос, т.е. конструкция SET оператора UPDATE должна перечислять колонки только одной таблицы из определения представления. Кроме того, чтобы представление, основанное на нескольких таблицах, было обновляемым, таблицы в его определении должны быть объединены только с помощью INNER JOIN, а не OUTER JOIN или UNION.
Обновляемое представление может допускать добавление данных (INSERT), если все поля таблицы-источника, не присутствующие в представлении, имеют значения по умолчанию.
Обратите внимание: для представлений, основанных на нескольких таблицах, операция добавления данных (INSERT) работает только в случае если происходит добавление в единственную реальную таблицу. Удаление данных (DELETE) для таких представлений не поддерживается.
При использовании в определении представления конструкции WITH [CASCADED | LOCAL] CHECK OPTION все добавляемые или изменяемые строки будут проверяться на соответствие определению представления.
- Изменение данных (UPDATE) будет происходить только если строка с новыми значениями удовлетворяет условию WHERE в определении представления.
- Добавление данных (INSERT) будет происходить только если новая строка удовлетворяет условию WHERE в определении представления.
Иными словами, нельзя добавить или изменить данные в представлении таким образом, чтобы они не были доступны через представление.
Ключевые слова CASCADED и LOCAL определяют глубину проверки для представлений основанных на других представлениях:
- Для LOCAL происходит проверка условия WHERE только в собственном определении представления.
- Для CASCADED происходит проверка для всех представлений на которых основанно данное представление. Значением по умолчанию является CASCADED.
Рассмотрим пример обновляемого представления, основанного на двух таблицах. Пусть наше представление выбирает темы форума с числом просмотров более 2000.
Однако, если мы попробуем установить значение num_views меньше 2000, то новое значение не будет удовлетворять условию WHERE num_views>2000 в определении представления и обновления не произойдет.
Не все обновляемые представления позволяют добавление данных:
Причина в том, что значением по умолчанию колонки forum_ >
С другой строны:
Таким образом, наше представление, основанное на двух таблицах, позволяет обновлять обе таблицы и добавлять данные только в одну из них.
Инструкция создания представления SQL
В SQL представление представляет собой виртуальную таблицу, основанную на результирующем наборе инструкций SQL.
Представление содержит строки и столбцы, точно так же, как реальная таблица. Поля в представлении представляют собой поля из одной или нескольких реальных таблиц в базе данных.
В представление можно добавить функции SQL, WHERE и JOIN, а также представить данные, как если бы данные поступили из одной таблицы.
Создать синтаксис представления
Примечание: В представлении всегда отображаются актуальные данные! Ядро СУБД повторно создает данные, используя инструкцию SQL View, каждый раз, когда пользователь запрашивает представление.
Примеры создания представлений SQL
Если у вас есть база данных Northwind, вы можете видеть, что она имеет несколько представлений, установленных по умолчанию.
В представлении «текущий список товаров» перечислены все активные продукты (продукты, которые не были прекращены) из таблицы «продукты». Представление создается с помощью следующего SQL:
Затем можно запросить представление следующим образом:
Другое представление в образце базы данных Northwind выбирает каждый продукт в таблице "Products" с ценой за единицу выше, чем средняя цена единицы:
Мы можем запросить представление выше следующим образом:
Другое представление в базе данных Northwind вычисляет общую продажу для каждой категории в 1997. Обратите внимание, что это представление выбирает свои данные из другого представления под названием "продажи продукта для 1997":
Мы можем запросить представление выше следующим образом:
Мы также можем добавить условие в запрос. Давайте посмотрим, Общая продажа только для категории "напитки":
SQL обновление представления
Можно обновить представление, используя следующий синтаксис:
Синтаксис представления SQL CREATE или Replace
Теперь мы хотим добавить столбец "Category" в представление "текущий список продуктов". Мы будем обновлять представление со следующим SQL:
SQL удаление представления
Можно удалить вид с помощью команды "Удалить вид".
[DEFINER = <user | CURRENT_USER>]
VIEW view_name [(column_list)]
[WITH [CASCADED | LOCAL] CHECK OPTION]
Эта инструкция создает новый view или заменяет существующий, если дано предложение OR REPLACE. Инструкция SELECT select_statement обеспечивает определение view. Инструкция может выбирать из основных таблиц или других views.
Эта инструкция требует привилегии CREATE VIEW для view и некоторой привилегии для каждого столбца, выбранного инструкцией SELECT. Для столбцов, используемых в другом месте в инструкции SELECT, Вы должны иметь привилегию SELECT. Если присутствует предложение OR REPLACE, Вы должны также иметь привилегию DROP для view.
Каждый view принадлежит базе данных. По умолчанию, новый view создан в заданной по умолчанию базе данных. Чтобы явно создавать view в указанной базе данных, определите его имя как db_name.view_name.
mysql> CREATE VIEW test.v AS SELECT * FROM t;
Основные таблицы и views совместно используют то же самое пространство имен внутри базы данных, так что база данных не может содержать основную таблицу и view, которые имеют то же самое имя.
Views должны иметь уникальные имена столбца без дубликатов, точно так же, как основные таблицы. По умолчанию, имена столбцов, найденных инструкцией SELECT используются для имени столбца view. Чтобы определять явные имена для столбцов view, может быть задано факультативное предложение column_list как список разделяемых запятой идентификаторов. Число имен в column_list должно быть таким же, как число столбцов, найденных командой SELECT.
Столбцы, найденные инструкцией SELECT, могут быть простыми ссылками к столбцам таблицы. Они также могут быть выражениями, которые используют функции, постоянные значения, операторы и т.д.
Неквалифицированная таблица или имя view в операторе SELECT интерпретируется относительно заданной по умолчанию базы данных. view может обратиться к таблицам или view в других базах данных, квалифицируя имя таблицы или view с соответствующим именем базы данных.
view может быть создан из многих видов инструкций SELECT. Он может обратиться к основным таблицам или другим view. Это может использовать объединения, UNION и подзапросы. SELECT не обязан обращаться к каким-либо таблицам. Следующий пример определяет view, который выбирает два столбца из другой таблицы, также как выражение, вычисленное из данных этих столбцов:
mysql> CREATE TABLE t (qty INT, price INT);
mysql> INSERT INTO t VALUES(3, 50);
mysql> CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;
mysql> SELECT * FROM v;
| qty | price | value |
Определение view подчиненно следующим ограничениям:
Инструкция SELECT не может содержать подзапрос в предложении FROM.
Инструкция SELECT не может обратиться к переменным пользователя или системы.
Инструкция SELECT не может обратиться к подготовленным операторным параметрам.
Внутри сохраненной подпрограммы, определение не может обратиться к стандартным параметрам или локальным переменным.
Любая таблица или view, упоминаемый в определении, должны существовать. Однако, после того, как view был создан, можно удалить таблицу или view, к которому определение обращается. В этом случае, использование view приводит к ошибке. Чтобы проверить определение view для выявления проблем этого вида, используйте инструкцию CHECK TABLE.
Определение не может обратиться к таблице типа TEMPORARY, и Вы не можете создавать TEMPORARY view.
Таблицы, поименованные в определении view, должны уже существовать.
Вы не можете связывать триггер с view.
ORDER BY позволяется в определении view, но это игнорируется, если Вы выбираете из view, используя инструкцию, которая имеет собственный ORDER BY.
Для других параметров или предложений в определении, которые добавлены к параметрам или предложениям инструкции, которая ссылается на view, эффект не определен. Например, если определение view включает предложение LIMIT, и Вы выбираете из view, применяя инструкцию, которая имеет собственное предложение LIMIT, не определено, которое ограничение применяется. Тот же самый принцип применяется к параметрам типа ALL, DISTINCT или SQL_SMALL_RESULT, которые следуют за ключевым словом SELECT, к предложениям типа INTO, FOR UPDATE, LOCK IN SHARE MODE и PROCEDURE.
Если Вы создаете view, а затем меняете среду, обрабатывающую запрос, меняя переменные системы, которые могут воздействовать на результаты, получаемые из view:
mysql> CREATE VIEW v AS SELECT CHARSET(CHAR(65)), COLLATION(CHAR(65));
Query OK, 0 rows affected (0.00 sec)
mysql> SET NAMES ‘latin1’;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM v;
1 row in set (0.00 sec)
mysql> SET NAMES ‘utf8’;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM v;
1 row in set (0.00 sec)
Предложения DEFINER и SQL SECURITY определяют контекст защиты, который нужно использовать при проверке привилегий доступа при вызове view. Они были добавлены в MySQL 5.0.13, но реально работают с MySQL 5.0.16.
CURRENT_USER также известен как CURRENT_USER().
Внутри сохраненной подпрограммы, которая определена с характеристикой SQL SECURITY DEFINER, CURRENT_USER возвращает создателя подпрограммы. Это также воздействует на view, определенный внутри такой подпрограммы, если определение view содержит значение DEFINER для CURRENT_USER.
Заданное по умолчанию значение DEFINER: пользователь, который выполняет инструкцию CREATE VIEW (поскольку DEFINER = CURRENT_USER). Если задано значение user, это должно быть логином MySQL в формате ‘user_name‘@’host_name‘ (тот же самый формат, используется в инструкции GRANT). Требуются значения user_name и host_name.
Если Вы определяете предложение DEFINER, Вы не можете устанавливать значение к любому пользователю, если не имеете привилегии SUPER. Эти правила определяют допустимые значения пользователя для предложения DEFINER:
Если Вы не имеете привилегии SUPER, единственное допустимое значение user: Ваш собственный логин, определенный буквально или используя CURRENT_USER. Вы не можете устанавливать DEFINER к некоторому другому логину.
Если Вы имеете привилегию SUPER, Вы можете определять любой синтаксически допустимый логин. Если он фактически не существует, будет сгенерировано предупреждение.
Характеристика SQL SECURITY определяет, который логин MySQL использовать при проверке привилегий доступа для view. Допустимые значения: DEFINER и INVOKER. Они указывают, что view должен быть выполним пользователем, который определил или вызвал его, соответственно. Заданное по умолчанию значение для SQL SECURITY: DEFINER.
Начиная с MySQL 5.0.16 (когда были введены в строй DEFINER и SQL SECURITY), привилегии view проверяются следующим образом:
При определении view создатель view должен иметь привилегии, необходимые, чтобы использовать объекты верхнего уровня, к которым обращается view. Например, если определение view обращается к сохраненной функции, могут быть проверены только привилегии, необходимые чтобы вызвать функцию. Привилегии, требуемые, когда функция выполняется, могут быть проверены только, когда это выполняется: для различных вызовов функции, могут приниматься различные пути выполнения внутри функции.
Во время выполнения view, привилегии для объектов, к которым обращается view, проверены относительно привилегий создателя или исполнителя view, в зависимости от того, является ли характеристика SQL SECURITY равной DEFINER или INVOKER.
Если выполнение view вызывает выполнение сохраненной функции, инструкции прверки привилегии, выполненные внутри функции, зависят от того, определена ли функция с характеристикой SQL SECURITY, равной DEFINER или INVOKER. Если характеристика защиты DEFINER, функция выполняется с привилегиями создателя. Если характеристика INVOKER, функция выполняется с привилегиями, определенными в соответствии с характеристикой SQL SECURITY для view.
До MySQL 5.0.16 привилегии, требуемые для объектов, используемых в view, проверялись при создании view.
Пример: view мог бы зависеть от сохраненной функции, и та функция могла бы вызывать другие сохраненные подпрограммы. Например, следующий view вызывает сохраненную функцию f():
CREATE VIEW v AS SELECT * FROM t WHERE t. >
Предположим, что f() содержит инструкцию типа этого:
IF name IS NULL then CALL p1();
Привилегии, требуемые для выполнения инструкций внутри f(), должны быть проверены, когда f() выполняется. Это могло бы означать, что привилегии необходимы для p1() или p2(), в зависимости от пути выполнения внутри f(). Те привилегии должны быть проверены во время выполнения, а пользователь, который должен обладать привилегиями, определен значениями SQL SECURITY функции f() и view v.
DEFINER и предложение SQL SECURITY для views представляют собой расширения к стандарту SQL. В обычном SQL views обработаны, используя правила для SQL SECURITY INVOKER.
Если Вы вызываете view, который был создан до MySQL 5.0.13, это обрабатывается, как если бы это было создано с предложением SQL SECURITY DEFINER и со значением DEFINER, равным Вашему логину. Однако, потому что фактический definer неизвестен, MySQL выдает предупреждение. Чтобы обойти предупреждение, достаточно вновь создать view, так чтобы определение view включило предложение DEFINER.
Факультативное предложение ALGORITHM задает расширение MySQL для стандартного SQL. ALGORITHM берет три значения: MERGE, TEMPTABLE или UNDEFINED. Заданный по умолчанию UNDEFINED, если никакое предложение ALGORITHM не присутствует. Алгоритм воздействует на то, как MySQL обрабатывает view.
Для MERGE текст инструкции, которая обращается к view, и определение view объединены так, что части определения view заменяют соответствующие части инструкции.
Для TEMPTABLE результаты из просмотра view помещаются во временную таблицу, которая затем используется, чтобы выполнить инструкцию.
Для UNDEFINED MySQL выбирает, который алгоритм использовать. Это предпочитает MERGE варианту TEMPTABLE, если возможно, поскольку MERGE обычно более эффективен и потому, что view не может быть обновляемым, если временная таблица используется.
Причина выбирать TEMPTABLE явно: блокировки на основных таблицах могут быть сняты после того, как временная таблица была создана, но прежде, чем это используется, чтобы закончить обрабатывать инструкцию. Это могло бы привести к более быстрому снятию блокировки, чем алгоритм MERGE так, чтобы другая клиентура, которая использует view, не была блокирована очень долго.
Алгоритм view может быть UNDEFINED по трем причинам:
Никакое предложение ALGORITHM не присутствует в инструкции CREATE VIEW.
Инструкция CREATE VIEW имеет явное предложение ALGORITHM = UNDEFINED.
ALGORITHM = MERGE определен для view, который может быть обработан только с временной таблицей. В этом случае MySQL генерирует предупреждение и устанавливает алгоритм к UNDEFINED (не к TEMPTABLE!).
Как упомянуто ранее, MERGE обработан, объединяя соответствующие части определения view в инструкцию, которая обращается к view. Следующие примеры кратко иллюстрируют, как работает алгоритм MERGE. Примеры принимают, что имеется view v_merge, который имеет это определение:
CREATE ALGORITHM = MERGE VIEW v_merge (vc1, vc2) AS
SELECT c1, c2 FROM t WHERE c3 > 100;
Пример 1: Предположим, что мы выдаем эту инструкцию:
SELECT * FROM v_merge;
MySQL обрабатывает инструкцию следующим образом:
v_merge становится t.
* становится vc1, vc2, которые соответствуют c1, c2.
Предложение WHERE из view добавляется.
Возникающая в результате инструкция, которая будет выполнена:
SELECT c1, c2 FROM t WHERE c3 > 100;
Пример 2: Предположим, что мы выдаем эту инструкцию:
SELECT * FROM v_merge WHERE vc1 100) AND (c1 CREATE TABLE t1 (a INT);
mysql> CREATE VIEW v1 AS SELECT * FROM t1 WHERE a 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.
