Имеются некоторые примеры модифицируемых представлений и представлений только_чтение:

CREATE VIEW Dateorders (odate, ocount)

AS SELECT odate, COUNT (*)

FROM Orders

GROUP BY odate;

Это - представление только_чтение из-за присутствия в нем агрегатной функции и GROUP BY.

CREATE VIEW Londoncust

AS SELECT *

FROM Customers

WHERE city='London';

А это - представление модифицируемое.

CREATE VIEW SJsales (name, number, percentage)

AS SELECT sname, snum, comm 100

FROM Salespeople

WHERE city='SanJose';

Это - представление только_чтение из-за выражения " comm * 100 " . При этом, однако, возможны переупорядочение и переименование полей. Некоторые программы будут позволять удаление в этом представлении или в порядках столбцов snum и sname.

CREATE VIEW Salesonthird

AS SELECT *

FROM Salespeople

WHERE snum IN

(SELECT snum

FROM Orders

WHERE odate=10/03/1990);

Это - представление только_чтение в ANSI из-за присутствия в нем подзапроса. В некоторых программах, это может быть приемлемо.

CREATE VIEW Someorders

AS SELECT snum, onum, cnum

FROM Orders

WHERE odate IN (10/03/1990,10/05/1990);

Это - модифицируемое представление.

Другой вывод о модифицируемости представления тот, что вы можете вводить значения которые " проглатываются " (swallowed) в базовой таблице. Рассмотрим такое представление:

CREATE VIEW Highratings

AS SELECT cnum, rating

FROM Customers

WHERE rating=300;

Это - представление модифицируемое. Оно просто ограничивает ваш доступ к определенным строкам и столбцам в таблице. Предположим, что вы вставляете (INSERT) следующую строку:

INSERT INTO Highratings

VALUES (2018, 200);

Это - допустимая команда INSERT в этом представлении. Строка будет вставлена, с помощью представления Highratings, в таблицу Заказчиков.

Однако когда она появится там, она исчезнет из представления, поскольку значение оценки не равно 300. Это - обычная проблема.

Значение 200 может быть просто напечатано, но теперь строка находится уже в таблице Заказчиков где вы не можете даже увидеть ее. Пользователь не сможет понять, почему введя строку он не может ее увидеть, и будет неспособен при этом удалить ее. Вы можете быть гарантированы от модификаций такого типа с помощью включения WITH CHECK OPTION (С ОПЦИЕЙ ПРОВЕРКИ) в определение представления. Мы можем использовать WITH CHECK OPTION в определении представления Highratmgs.

CREATE VIEW Highratings

AS SELECT cnum, rating

FROM Customers

WHERE rating=300

WITH CHECK OPTION;

Вышеупомянутая вставка будет отклонена.

WITH CHECK OPTION - производит действие все_или_ничего (all-or-nothing). Вы помещаете его в определение представления, а не в команду DML, так что или все команды модификации в представлении будут проверяться, или ни одна не будет проверена. Обычно вы хотите использовать опцию проверки, используя ее в определении представления, что может быть удобно.

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

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

CREATE VIEW Londonsta1t

AS SELECT snum, sname, comm

FROM Salespeople

WHERE city='London';

В конце концов, зачем включать значение city, если все значения city будут одинаковыми.

А как будет выглядит картинка получаемая всякий раз, когда мы пробуем вставить строку. Так как мы не можем указать значение city как значение по умолчанию, этим значением вероятно будет NULL, и оно будет введено в поле city (NULL используется если другое значение по умолчанию значение не было определено. См. Главу 18 для подробностей ).