Представления (VIEW) в MySQL - Создание представлений

Создание представлений

Для создания представления используется оператор CREATE VIEW, имеющий следующий синтаксис:

CREATE [OR REPLACE]
[ALGORITHM = {UNDEFINED / MERGE / TEMPTABLE}]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED / LOCAL] CHECK OPTION]

view_name - имя создаваемого представления. select_statement - оператор SELECT, выбирающий данные из таблиц и/или других представлений, которые будут содержаться в представлении

Оператор CREATE VIEW содержит 4 необязательные конструкции:

1. OR REPLACE - при использовании данной конструкции в случае существования представления с таким именем старое будет удалено, а новое создано. В противном случае возникнет ошибка, информирующая о сществовании представления с таким именем и новое представление создано не будет. Следует отметить одну особенность - имена таблиц и представлений в рамках одной базы данных должны быть уникальны, т.е. нельзя создать представление с именем уже существующей таблицы. Однако конструкция OR REPLACE действует только на представления и замещать таблицу не будет.
2. ALGORITM - определяет алгоритм, используемый при обращении к представлению (подробнее речь об этом пойдет ниже).
3. column_list - задает имена полей представления.
4. WITH CHECK OPTION - при использовании данной конструкции все добавляемые или изменяемые строки будут проверяться на соответствие определению представления. В случае несоответствия данное изменение не будет выполнено. Обратите внимание, что при указании данной конструкции для необновляемого представления возникнет ошибка и представление не будет создано. (подробнее речь об этом пойдет ниже).

По умолчанию колонки представления имеют те же имена, что и поля возращаемые оператором SELECT в определении представления. При явном указании имен полей представления column_list должен включать по одному имени для каждого поля разделенных запятой. Существует две причины по которым желательно использовать явное указание имен полей представления:

1. Имена полей представления должны быть уникальны в пределах данного представления. При создании представления основанного на нескольких таблицах возможна ситуация повторения имен полей представления. Например:

   CREATE VIEW v AS SELECT a.id, b.id FROM a,b;

   Для избежания такой ситуации нужно явно указывать имена полей представления
   

   CREATE VIEW v (a_id, b_id) AS SELECT a.id, b.id FROM a,b;

   Того же результата можно добиться, используя синонимы (алиасы) для названий колонок:
   

   CREATE VIEW v AS SELECT a.id a_id, b.id b_id FROM a,b;

2. В случае если в определении представления получаемые данные преобразуются с помощью каких-то функций, то именем поля будет данное выражение, что не очень удобно для дальнейших ссылок на это поле. Напимер:
   

   CREATE VIEW v AS SELECT group_concat(DISTINCT column_name oreder BY column_name separator `+`) FROM table_name;

   Вряд ли удобно использовать в дальнейшем в качестве имени поля `group_concat(DISTINCT username ORDER BY username separator `+`)`

Для просмотра содержимого представления мы используем оператор SELECT (полностью аналогично как в случае простой таблицы), с другой строны, оператор SELECT есть в самом определении представления, т.е. получается вложенная конструкция - запрос в запросе. При этом, некоторые конструкции оператора SELECT могут присутствовать в обоих операторах. Возможны три варианта развития событий: они обе будут выполнены, одна из них будет проигнорированна и результат неопределен. Рассмотрим подробнее эти случаи:

1. Если в обоих операторах встречается условие WHERE, то оба этих условия будут выполнены как если бы они были объединены оператором AND.
2. Если в определении представления есть конструкция ORDER BY, то она будет работать только в случае отсутствия во внешнем операторе SELECT, обращающемся к представлению, собственного условия сортировки. При наличии конструкции ORDER BY во внешнем операторе сортировка, имеющаяся в определении представления, будет проигнорирована.
3. При наличии в обоих операторах модификаторов, влияющих на механизм блокировки, таких как HIGH_PRIORITY, результат их совместного действия неопределен. Для избежания неопределенности рекомендуется в определении представления не использовать подобные модификаторы.