VIEWs. Альтернативный способ представления данных.

Бывает ситуации, в которых нам необходимо работать с данными, уже приведенными к какому-то виду. Например, нам нужно подготовить данные для расписания, где у нас уже будут Фамилии преподавателей, номера групп, название предметов, вместо ID. Либо, таблица всех рейсов-маршрутов. Самый простой способ - сделать подзапрос. Так это и делается. А что, если эта таблица, получившаяся с подзапросе, предполагает частое использование? Наш опыт нам подсказывает каким-либо образом сохранить этот запрос. Собственно, эту задачу и берет на себя представление (VIEW).

Представление (VIEW) - именованный SELECT-запрос.

Создать представление можно следующим образом:

CREATE VIEW viewName AS <someSelectQuery>;

То есть мы даем представлению имя. И вместо <someSelectQuery> пишем любой SELECT-запрос. И после этого мы можем использовать наше представление, как обычную таблицу:

SELECT * FROM viewName;

Учтите, одноименных таблиц в БД быть не должно. То есть представления и таблицы имеют общее пространство имен. Более того, по запросу вы не сможете понять, является ли это таблицей, либо представлением. По-факту, происходит подстановка и выполняется вложенный запрос. При этом существуют различные типы представлений, в частности, в PostgreSQL есть такие (materialized view), которые существуют на самом деле.

Для удаления используем команду DROP:

DROP VIEW viewName;

Важное отличие в том, что изначально представления считаются read-only, то есть мы не можем внести в них изменения. И если задуматься, это логично - как мы можем внести изменения в данные, которые мы получили с помощью SELECT-запроса?

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

  • основывается только на одной базовой таблице;
  • содержит первичный ключ этой таблицы;
  • не содержит DISTINCT в своем определении;
  • не использует GROUP BY или HAVING в своем определении;
  • по возможности не применяет в своем определении подзапросы;
  • не использует константы или выражения значений среди выбранных полей вывода;
  • в просмотр должен быть включен каждый столбец таблицы, имеющий атрибут NOT NULL;
  • оператор SELECT просмотра не использует агрегирующие (итоговые) функции, соединения таблиц, хранимые процедуры и функции, определенные пользователем;
  • основывается на одиночном запросе, поэтому объединение UNION не разрешено.

Вопросы

  1. Как узнать по имени отношения - таблица это или представление?
  2. Где хранится информация о представлениях?

results matching ""

    No results matching ""