Биохимия спиртового брожения: Основу технологии получения пива составляет спиртовое брожение, - при котором сахар превращается...
Индивидуальные очистные сооружения: К классу индивидуальных очистных сооружений относят сооружения, пропускная способность которых...
Топ:
Когда производится ограждение поезда, остановившегося на перегоне: Во всех случаях немедленно должно быть ограждено место препятствия для движения поездов на смежном пути двухпутного...
Интересное:
Подходы к решению темы фильма: Существует три основных типа исторического фильма, имеющих между собой много общего...
Искусственное повышение поверхности территории: Варианты искусственного повышения поверхности территории необходимо выбирать на основе анализа следующих характеристик защищаемой территории...
Распространение рака на другие отдаленные от желудка органы: Характерных симптомов рака желудка не существует. Выраженные симптомы появляются, когда опухоль...
Дисциплины:
|
из
5.00
|
Заказать работу |
Содержание книги
Поиск на нашем сайте
|
|
|
|
Конструкцию 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).
Не помешает обзавестись специальной программой, которая проверяла бы наличие представлений, на которые нигде нет ссылки. Проверяйте также, нет ли у вас двух представлений, решающих одну и ту же или почти одну и ту же задачу. Если таковые найдутся, удалите одно из них.
Исключения
Нет.
Синхронизируйте представления с базовыми таблицами
Обоснование
При любом изменении базовой таблицы необходимо анализировать все основанные на ней представления, чтобы выяснить, затрагивает ли их это изменение. Все представления должны оставаться логически чистыми, выполняя то предназначение, для которого вы их создали.
Допустим, имеется представление, созданное для управления доступом сотрудников к проекту. Мы решили добавить в базовую таблицу “Персонал” столбец с номерами пропусков. Вероятно, этот столбец нужно включить и в представление. В таблицу столбец добавляется немедленно, в представление — при первой возможности.
Правила синхронизации предполагают, что в системе есть процедуры, предназначенные для тщательного анализа последствий изменения в базовой таблице. Эти процедуры должны автоматически вызываться при любой правке базовой таблицы.
Исключения
Нет.
|
|
|
История создания датчика движения: Первый прибор для обнаружения движения был изобретен немецким физиком Генрихом Герцем...
Кормораздатчик мобильный электрифицированный: схема и процесс работы устройства...
Типы сооружений для обработки осадков: Септиками называются сооружения, в которых одновременно происходят осветление сточной жидкости...
Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...
© cyberpediasu.com 2017-2026 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!