Конструкция with check option
Конструкцию WITH CHECK OPTION в описании представления явно недооценивают. Конечно, непросто разобраться в том, как она работает во вложенных представлениях. Но суть ее такова: она не дает операторам UPDATE и INSERT INTO выйти за пределы набора значений, заданного для обновляемого представления. Рассмотрим, например, такое представление:
CREATE VIEW NewYorkSalesmen (ssn, name, ...)
AS
SELECT ssn, name, ...
FROM Salesmen
WHERE city = 'New York';
Теперь обновим его:
UPDATE NewYorkSalesmen SET city = 'Boston';
В результате при следующем обращении к представлению NewYorkSalesmen оно окажется пустым. Вряд ли мы добивались именно этого. А вот если бы мы определили представление так:
CREATE VIEW NewYorkSalesmen (ssn, name, ...)
AS
SELECT ssn, name, ...
FROM Salesmen
WHERE city = 'New York' WITH CHECK OPTION;
система обнаружила бы нарушение и отвергла бы обновление.
Триггеры INSTEAD OF
Некоторые представления нельзя обновлять, но вы можете скрыть это от пользователя с помощью триггера INSTEAD OF. Он выполняется при попытке выполнить действия INSERT, UPDATE или DELETE, заменяя их. Синтаксис от продукта к продукту меняется, но в целом выглядит как-то так:
CREATE TRIGGER <имя триггера>
ON <имя таблицы>
[BEFORE | AFTER | INSTEAD OF]
[INSERT| DELETE | UPDATE]
AS [<выражение SQL> | BEGIN ATOMIC {<выражение SQL>;} END]
Понятно, что для каждой таблицы или представления можно определить только по одному триггеру INSTEAD OF на выражение INSERT, UPDATE или DELETE. Однако допускается создавать одно представление на основе другого, задавая в каждом из них собственный триггер INSTEAD OF. Использовать триггеры INSTEAD OF в обновляемых представлениях с параметром WITH CHECK OPTION нельзя. Вместо этого можно определить триггер INSTEAD OF в описании базовой таблицы, но это будет несколько странно, поскольку в вашем распоряжении есть триггеры BEFORE и AFTER.
Не создавайте представления просто так
Обоснование
Представление нужно создавать только с определенной разумной целью. У каждого представления должно быть определенное предназначение, которое обязательно документируется, предпочтительнее, в словаре данных или хотя бы в виде комментария в определении представления.
Исключения
Нет.
Не давайте представлениям размножаться
Обоснование
Смысл этого правила очень прост. Зачем создавать что-то ненужное? Оно просто напросто занимает место, которое можно было бы занять чем-нибудь нужным.
При создании любого объекта SQL в информационные таблицы схемы добавляются новые записи. Создание ненужных объектов схемы приводит к тому, что Крейг Маллинс (Craig Mullins) называет забиванием каталога. Например, в DB2 для каждого представления SQL могут создаваться строки в четырех информационных таблицах схемы, связанных с представлениями (SYSVTREE, SYSVLTREE, SYSVIEWS и SYSVIEWDEP), и трех информационных таблицах схемы, связанных с таблицами (SYSTABLES, SYSTABAUTH и SYSCOLUMNS).
Не помешает обзавестись специальной программой, которая проверяла бы наличие представлений, на которые нигде нет ссылки. Проверяйте также, нет ли у вас двух представлений, решающих одну и ту же или почти одну и ту же задачу. Если таковые найдутся, удалите одно из них.
Исключения
Нет.
Синхронизируйте представления с базовыми таблицами
Обоснование
При любом изменении базовой таблицы необходимо анализировать все основанные на ней представления, чтобы выяснить, затрагивает ли их это изменение. Все представления должны оставаться логически чистыми, выполняя то предназначение, для которого вы их создали.
Допустим, имеется представление, созданное для управления доступом сотрудников к проекту. Мы решили добавить в базовую таблицу “Персонал” столбец с номерами пропусков. Вероятно, этот столбец нужно включить и в представление. В таблицу столбец добавляется немедленно, в представление — при первой возможности.
Правила синхронизации предполагают, что в системе есть процедуры, предназначенные для тщательного анализа последствий изменения в базовой таблице. Эти процедуры должны автоматически вызываться при любой правке базовой таблицы.
Исключения
Нет.