Oracle кто изменил объект

Обновлено: 06.07.2024

Oracle/PLSQL оператор EXECUTE IMMEDIATE подготавливает (анализирует) и немедленно выполняет динамический SQL-запрос или анонимный PL/SQL блок.
Основным аргументом EXECUTE IMMEDIATE является строка, содержащая SQL-запрос для выполнения. Вы можете создать строку, используя конкатенацию, или использовать предопределенную строку.
Динамическая строка может содержать любой оператор SQL (без последней точки с запятой), за исключением многострочных запросов или любой PL/SQL блок (с последней точкой с запятой).
Строка dynamic_string также может содержать заполнители, произвольные имена, которым предшествует двоеточие, для аргументов связывания bind_argument . В этом случае вы указываете, какие переменные PL/SQL соответствуют заполнителям, с помощью операторов INTO, USING и RETURNING INTO. Во время выполнения аргументы связывания заменяют соответствующие заполнители в динамической строке. Каждый заполнитель должен быть связан с аргументом связывания в предложении USING и/или предложении RETURNING INTO.

Синтаксис

Синтаксис Oracle/PLSQL оператора EXECUTE IMMEDIATE для передачи значения в переменную или строку:

EXECUTE IMMEDIATE dynamic_string
[ INTO <[define_variable[, define_variable] . | record_name>]
[USING [IN | OUT | IN OUT] bind_argument ]
returning_clause;

или синтаксис Oracle/PLSQL оператора EXECUTE IMMEDIATE для передачи значения в коллекцию

EXECUTE IMMEDIATE dynamic_string
[[ BULK COLLECT] INTO ]
[USING [IN | OUT | IN OUT] bind_argument]
returning_clause;

Параметры или аргументы

dynamic_string Строковый литерал, переменная или выражение, представляющее один оператор SQL или блок PL/SQL. Он должен иметь тип CHAR или VARCHAR2, а не NCHAR или NVARCHAR2. BULK COLLECT Сохраняет значения результатов в одной или нескольких коллекциях для более быстрых запросов, чем циклы с операторами FETCH. INTO Используется только для однострочных запросов, в этом разделе указываются переменные или записи, в которые извлекаются значения столбцов. Для каждого значения, полученного запросом, в предложении INTO должна быть соответствующая тип-совместимая переменная или поле. define_variable Переменная, в которой сохраняется значение выбранного столбца. record_name Пользовательская запись или запись %ROWTYPE, в которой сохраняется выбранная строка. bind_argument Выражение, значение которого передается в динамический оператор SQL, или переменная, в которой сохраняется значение, возвращаемое динамическим оператором SQL. collection_name Объявленная коллекция, в которую извлекаются значения select_item из dynamic_string . Для каждого select_item должна быть соответствующая, совместимая с типом коллекция в списке. host_array_name Массив (объявленный в хост-среде PL/SQL и переданный PL/SQL как переменная связывания), в который извлекаются значения select_item. Для каждого select_item должен быть соответствующий, совместимый с типом массив в списке. Массивы хоста должны начинаться с двоеточия. USING По умолчанию - IN. Определяет список входных и/или выходных аргументов привязки. returning_clause Возвращает значения из вставленных строк, устраняя необходимость SELECT строки после. Вы можете извлечь значения столбца в переменные или в коллекции. Вы не можете использовать предложение RETURNING для удаленной или параллельной вставки. Если инструкция не влияет ни на какие строки, значения переменных, указанных в предложении RETURNING, не определены.

Примеры:

Некоторые примеры динамического SQL

Рассмотрим несколько примеров использования Oracle/PLSQL оператора EXECUTE IMMEDIATE, чтобы понять как использовать EXECUTE IMMEDIATE в Oracle/PLSQL.
Описание команд в комментариях (--).

1. Делается GUI-приложение, в котором имеется возможность на основе метаинформации о базе данных (информации о структуре базы) выбирать какие схемы / таблицы / поля отслеживать. Названия объектов за которыми происходит слежение заносится в некую таблицу (ну или список таблиц, неважно).
Также GUI включает в себя средство просмотра самой информации по изменению таблиц в удобном виде (фильтрация и прочее).

2. Существует скрипт БД. Что он делает - проходит по всей базе (по всем схемам или как вариант по некоторым схемам) и к каждой таблице добавляет триггер на insert, update, delete. При срабатывании этого тригера идет запрос к таблицам описания слежения и проверяется, нужно ли вести историю этой таблицы, полей этой таблицы. Если нужно - то старая информация скидывается в дублирующую таблицу (структура которой включает в себя полностью структуру таблицы за которой идет слежение). Таким образом в дублирующей таблице будет история изменения записей.
По прошествии времени, каких-то условий, информация из дублирующих таблиц будет скидываться в дамп и отправляться в архив.
Думаю, в целом принцип ясен, если что - задавайте вопросы.

Некоторые моменты. Почему ко всем таблицам прилепляются триггеры? Чтобы не мучатся с синхронизацией метаописания слежения и реальным положением в базе, не делать сверки и подобное. Что-то не так - бац, пересоздал триггер для всех таблиц, текст триггера однотипный достаточно, для всех таблиц может иметь одинаковое названия типа "__history_trigger". Да, мы понимаем, что это замедляет работу со вставкой, удалением и апдейтом данных, по нашим экспериментам в несколько раз, но это допустимо, железо перекрывает потребности в производительности, а задача такая стоит.

Но такое количество триггеров, конечно, в какой-то степени удручает (особенно, если слежение производится за 15 таблицами, а всего таблиц 500 и получается 500 триггеров). Возможно, есть какие-то триггеры на схему? Вроде бы есть триггер на всю БД, но он сильно системный и туда попадает множество лишней информации, типа создание таблиц, дропа, создание хранимок, триггеров ну и прочее.

Знаем, что в oracle есть трейс, куда скидывается в текстовом виде информация об изменении данных. Но информация текстовая, распарсивать оочень не хочется. И есть подозрение, что включать трейс на промышленной, боевой БД все таки не стоит.

Также есть подозрение, что задача не уникальная и встречались с ней многие. Возможно, есть выработанные стандартизированные методы подхода? На настоящее время с кем общались - все делали кто во что горазд. Зачастую это делается системной вещью, типа налепить триггеров и они будут скидывать информацию об обновлении. Когда потребуется разборка - в руки любимый софт для работы с БД и вручную разбираться что и когда. У нас, к сожалению, стоит задача сделать немного в более удобном виде, с управлением через GUI и просмотром истории там же.

Таким образом принимается любая критика по описанному подходу, какие подводные камни могут встретиться, опыт по созданию такой системы мониторинга может у кого есть? Какие места будут сложные в реализации, что стоит учесть в самом начале? Возможно, существуют совершенно другие подходы к реализации этой задачи, возможно основанные на специфике оракла, возможно там даже с написанием каких-то системных плагинов расширения (DLL, so или подобное). Любые мысли, пожалуйста :-)

1) поскольку триггеры создаются ко всем таблицам - исчезает проблема синхронизации. Но остается проблема создания и поддержания в актуальном виде дублирующих таблиц. Конечно, можно КАЖДОЙ таблице делать дублирующую историческую таблицу (даже если нет слежения за этой таблицей), но это, наверное, уже перебор. Но иначе нужно как-то следить. Тут стоить представить процесс разработки. Допустим, перерисовали таблицу под измененные бизнес-требования в каком-нибудь редакторе структуры таблиц. Внесли изменение в таблицу, внесли изменение в клиентское ПО, сделали скрипт обновления структуры для обновления до новой версии ПО.
А вот дублирующую таблицу изменить забыли. В результате триггер исторический может начать плеваться exception и застопорить вставку, обновление и удаление данных. И пятая точка чует, что таких косячков будет немало. Очень интересен опыт тех, кто внедрял подобную систему, с чем больше всего намучались, насколько это усложнило разработку и главное ПОДДЕРЖКУ систем?

2) чисто техническая фишка. По идее триггер должен сработать САМЫМ первым, чтобы унести в историческую дублирующую таблицу старые данные. Ибо если перед ним сработает другой триггер, то там уже могут оказаться не реальные старые данные, а какие-нибудь данные сформированные триггером, сработавшим раньше. ну или что-то в этом роде.

Сугубо ИМХО все.
Вместо нормальной работы по контролю доступа, разграничению прав и проработки бизнес логики предлагается глобальная шняга, которая, если заработает, будет жрать диски и другие ресурсы со скоростью на порядки превышающей нормальную.

Для простейшего контроля достаточно добавить в критические таблицы 2 поля - временнУю метку и юзернейм последнего редактирования записи.

для дешевых применений написать триггер, который записывает значения в сделанные руками таблицу аудита.

> Вместо нормальной работы по контролю доступа, разграничению
> прав и проработки бизнес логики предлагается глобальная
> шняга

это имеет крайне посредственное отношение к разграничению доступа и правам. Человек вполне может иметь права сделать ДЕЙСТВИЕ, но это не отменяет задачи при наличии желания узнать КТО конкретно сделал этот действие.

вроде ссылок надавали.
Кайта еще читать не повредит

А вы могли бы навскидку перечислить основные минусы, плюсы подходов:

> без админских прав? шо, серьезно?

Без админских, а что ? Прав владельца хватает.

> ну тогда ораклу надо выкрасить и быбросить.

Я ничего не придумываю. Я описываю варианты. Твое описание подходит под "мой" вариант №2
> Если все нормально, но нужна история изменения - значит система просто недоработана. Причем именно в этом месте, а не вообще.

Охота вместо фиксации юзера/времени в критической таблице делать систему глобального аудита - флаг в руки. Я сразу заявил, что

> Сугубо ИМХО все.

так вот, без всякого трындежа, залезу под юзером безправным, который пользует одну табличку по чтению/записи, и у котрой есть триггер. и убЪю гада! без трындежа? так таки убью? или не стоит руки марать?

> а можешь матчасть почитать

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

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

зы. а юзер таки нифига не видит. и это правильно.

> хотелось простоты и красивости

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

Владелец - это тот, кто создал объект (таблицу, триггер, еще что-нибудь).
Владелец же может дать права на таблицу, триггер, еще что-нибудь, кому угодно. Причем, права разные - от чтения до модификации и выполнения.

> ежели права владельца раздавать всем, кому не попадя, то
> кто кому доктор?

Права владельца не раздаются, они существуют и раздать их нельзя, насколько мне известно.

Существуют права, которое плюют на владельца, в их названии присутствует слово ANY (например, DROP ANY TRIGGER), такие права тоже могут быть даны кому угодно (но даются редко)

Кто такой юзер в этом контексте - я не понимаю. Если просто посторонний по отношению к владельцу объекта, так он объекта даже не увидит, не говоря о том, чтобы изменить, удалить и прочее, опять же, если владелец не предоставил права любому (PUBLIC)

> Существуют права, которое плюют на владельца

видимо, что-то типа SYSDBA, правда, я под ним не ходил(и аудит из-под него-же, наскоько я понимаю). Игорь, согласись, глупо отлавливать тех, кто наделен полными полномочиями по отношению к объекту (подразумеваются данные в таблицах, опять же). ну, как правило. я так понимаю, что такими правами наделяют людей вполне адекватных? хотя, их тоже можно ловить, но это уже именно из админа.

Когда задача решена, все изменения в БД переносятся из девелоперской схемы в тестовую, но при этом раздаются нужные права, а владельцем новых объектов БД становится админ. В тестовой схеме разработчик имеет ограниченные права - лишь те, что нужны ему для тестирования (например, права конечного юзера плюс права на просмотр чего-то). Тем самым, в процессе тестирования проверяется как новый функционал, так и правильность скриптов переноса из схемы в схему и раздачи прав.

Икру люблю и черную и красную, но к сожалению натуральную, и действительно вкусную в наше время.

Если вас интересуют в первую очередь качественные запчасти к бензиновому триммеру, то могу.

У меня есть пару автомобилей которые работают в такси и я раз в месяц делаю полную дезинфекцию.

Если у вас есть домашний любимец и мы заметили что с ним что-то не так, а времени у вас нет.

Я всегда обращаюсь к этим ребятам так как они качественно делают свою работу.

Как сменить пароль по умолчанию для схемы SYSTEM c 'manager' на свой? То же и для SYS

Подскажите, есть ли в PL\SQL команда, определяющая операционную систему?

Собственно, сабж :), касаемо ооочень большого предприятия. Помогите с аргументацией.

Народ. помогите лентяю - где можно накачть документацию по Oracle (не ниже 8i) на русском.

А поступить в случае, когда основная схема ничего не знает о тех схемах, которые, по идее, надо.

при использовании TO_CHAR(volume), где volume - NUMBER, если целая часть числа равна 0 (например.

делаю запрос "SELECT Column1 FROM Table1 WHERE nameid=123456" я не знаю сколько будет.

Приветствую Знающих! проскажите пожалуйста как составить sql запрос выводящий список.

Есть поле типа BLOB, в котором храниться документ в формате PDF. Необходимо извлечь данные из.

Периодически на сервере процесс Oracle грузит процессор на 100% на длительное время. В.

Добрый день! Столкнулась с такой проблемой при работе с OLAP-кубами в Excel с установленной.

После установки Oracle 8.1.7 на Windows 2000 сервере (Whistler) пытаюсь создать БД с помощью.

Очень, очень, очень, очень, очень, очень, очень не удобно сделаны комменты у вас! они нужны.

Помогите начать! Установил Oracle9i, при попытке войти в SQL*Plus запрашивает логин и пароль.

Помогите, пожалуйста, советами. С базой нельзя соединиться, возникает ora-01033. В логах.

это что издевательство такое? Oracle 7? где вы его сейчас увидите? Фильтруйте хоть немного.

Как-то не кажется, что это так "наболело". Можно было бы привести более серьёзный примерчик.

У меня Oracle 9i. Скачал на днях Designer. Поставил. При попытке запуска (des2k61.exe.

Плиз помогите, где взятьбазу данных oracle последней верссии

С помощью пакета DBMS_JOB создается JOB c указанием NEXT_DATE (даты запуска) и интервалом null.

у меня ест таблица имеющая тип BLOB и файлы хранящийся в этой таблице. Подскажите как из этой.

не как не пойму как скачать на официальном сайте Oracle Database 10g Express Edition .может кто.

Какие могут быть ошибки при установке Oracle на Windows 7 [64

Всем привет, подскажите пожалуйста как правильно установить Оракл на Линукс, может быть есть.

Доброго времени суток. У меня такая проблема: есть три таблицы: Заявка_на_недвижимость, Документ.

Добрый день! Ситуация следующая: при запуске формы происходит замена текущей схемы (alter.

Система Solaris 5.9, устанавливаем Oracle 9.0.2.1 После установки и отработке netca.

Люди добрые! Подмогните кто чем может! Сервер под Win 2003, поставил DB Oracle 10g. Вроде все.

Как с правами администратора прослеживать SQL-запросы выполненные DB Oracle 10g ?

Ошибка "/ вместо |" Есть: Сохраним и закроем файл. Затем импортирем ключ GPG: $ wget.

Процедура находится в пакете pac1 В этом пакете объявлен тип: type cur is ref cursor. В этом.

Мы создаем инструментальное средство разработки баз данных Oracle - 'Database Voyager'. Ввиду.

помогите пожалуйста! Мне надо написать курсовую по СУБД Oracle. Даже не знаю с чего начать.

Помогите новичку разобраться с инсталляцией. Есть оракл 9 на 3-х дисках. На первом диске -.

Помогите пожалуйста, не удается инсталлировать OracleClient 8 (8.1.7). Жмешь на Setup.exe и.

После патча Оракла 8.1.7.0.0 до 8.1.7.4.1 перестал выполняться export В чем проблема, помогите.

Подскажите, можно ли в уже имеющейся базе изменить настройки разделителя целой/дробной части.

Кто нибудь ставил mod_owa под Unix (Solaris)? Поделитесь опытом, плиз.

Мне кажется, что нужно использовать аналитические функции : create table T_CURRENCY ( CODE .

Здравствуйте, при запуске PLSQL Developer выдаёт следующую ошибку: ORA-12560: TNS:ошибка.

Да разве б не цвела земля афинская,
Когда бы так же рассуждали граждане
И постоянно не искали нового?

Аристофан, Женщины в народном собрании

Реферат

В версии Oracle 11.2 для некоторых видов объектов хранения была введена возможность заводить одновременно несколько «редакций» (editions). Она была придумана для совершенствования процесса внесения изменений в схему данных, позволяя в некоторых случаях отлаживать новый вариант приложения впараллель с работой текущего. Техника использования редакций объектов рассматривается в статье на примерах.

Содержание

Введение

VIEW
SYNONYM
PROCEDURE
FUNCTION
TRIGGER
PACKAGE/PACKAGE BODY
TYPE/TYPE BODY
LIBRARY.

Основное применение техники редакций объектов можно видеть в области и поддержки и развития приложения. Она позволяет выполнять часть работ по внесению изменений в существующее прикладное ПО без останова использования рабочей системы и отлаживать нововведения впараллель основной работе.

Хотя техника редакций объектов хранения не распространяется на данные в исходных таблицах БД, версии представлений иногда помогают подготовить приложение в том числе к переходу на новые структуры таблиц.

В версии Oracle 11.2 техника редакций объектов воплощена в своем начальном варианте, вероятно не окончательном.

Далее рассматривается несколько примеров создания и использования версий объектов в Oracle.

Подготовка схемы для редакций объектов

Ниже приводятся команды заведения в SQL*Plus схемы для объектов разных редакций и выполнения необходимых сопутствующих действий.

В схеме YARD появилась таблица EMP с той же структурой, что и одноименная в схеме SCOTT и с теми же данными (но без ограничений целостности).

Создание редакций для объектов и управление ими

Управление редакциями регулируется привилегиями CREATE/ALTER/DROP ANY EDITION. Слово ANY в названиях напоминает о внесхемном характере редакций, распространяющемся на уровень всей БД целиком (формально они все приписаны пользователю SYS).

Если правом создавать редакции объектов и управлять ими требуется доверить пользователю YARD, администратору БД следует продолжить:

Узнать действующую в данный момент редакцию можно из контекста сеанса USERENV (встроенного в СУБД):

ORA$BASE – это встроенная в БД умолчательно действующая редакция, на основе которой администратор может создавать последовательность редакций (а в будущих версиях Oracle возможно дерево) на свое усмотрение. Имя умолчательной для БД редакции можно выяснить запросом:

Примеры создания редакций:

В первом случае редакция APP_RELEASE_1 была создана на основе умолчательно действующей редакции ORA$BASE, во втором – как следует из текста команды.

Откомментировать редакцию в словаре-справочнике БД можно командой COMMENT:

Снять комментарий можно, указав пустую строку ''. Наблюдаются комментарии через таблицу ALL_EDITION_COMMENTS.

Узнать существующие редакции в их взаимосвязи можно запросом к особой таблице:

Удалить можно только лист из дерева (пока – ветки), свободный от подчиненных редакций:

Для того, чтобы пользователь Oracle мог не просто обращаться с редакциями объектов, но и формировать их, ему следует сообщить особое качество:

Качество ENABLE EDITIONS не изначальное и неотъемлемое; буде оно раз выдано, отменить его нельзя. В результате все пользователи Oracle оказываются разделены на две категории: тех, кому разрешено формировать редакции, и тех, кому не разрешено. При том возможен перевод пользователя из второй категории в первую, но никак не обратно. Удостовериться в наличие свойства ENABLE EDITIONS у пользователя можно по значению поля EDITIONS_ENABLED (нового в версии 11.2) в таблице DBA_USERS (владелец ее SYS, и обычным пользователям сама по себе она не видна).

После выдачи последней команды каждый объект пользователя YARD, для которого разрешено редактирование, так или иначе будет привязан к какой-нибудь редакции.

Настройка на работу с нужной редакцией

он должен иметь привилегию на работу с редакцией, выданную лично ему или, вместо этого, псевдопользователю PUBLIC (то есть всем вообще);
сеанс должен быть переключен на работу с этой редакцией.

Выдать пользователю личное общее разрешение на работу с объектами требуемой редакции можно примерно так:

USE – это привилегия на объекты вида EDITION, передаваемая к тому же через PUBLIC и через роли. Если редакцию, объявить в БД умолчательной, она автоматически полагается выданной для PUBLIC, то есть общедоступной, и не требует личных (или же ролевых) разрешений. По этой причине изначально частных разрешений на работу с ORA$BASE не требуется – оно есть у всех. То же самое произойдет с редакцией APP_RELEASE_1, если в какой-то момент выдать:

На последнюю команду способен обладатель привилегии ALTER DATABASE (а ею обладают SYS и SYSTEM, но пока что не YARD). Как только такая команда будет выдана, команды GRANT USE, как выше, для придания нужных полномочий пользователю SCOTT, не потребуется. Выдачей подобной команды может венчаться отладка новых редакций объектов («перевод приложения на новую редакцию»).

Когда пользователь Oracle получил разрешение (то есть привилегию) на работу с объектами конкретной редакции, он получает право в рамках отдельных сеансов настраиваться на нее:

Код выше подтверждает то, что по умолчанию при открытии сеанса действует редакция, объявленая ранее умолчательной в БД.

Пример создания и использования разных редакций представления данных (view)

К настоящему моменту в БД имеется две редакции. Будем формировать их содержание редакциями объектов в схеме YARD. Создадим в ней две несложные редакции одного и того же представления данных – с выдачей сведений об отделе сотрудника, и без:

Настройку на редакцию ORA$BASE можно было выше не выполнять, потому что эта редакция умолчательная (это проверялось ранее), и автоматически действует в начале каждого сеанса.

В результате появились две редакции представления данных EMP_VIEW:

Редактируемые представления данных (editioning views) отличаются от обычных не только формальным словом EDITIONING при создании, но и некоторыми техническими свойствами. Они могут строиться на основе единственной таблицы, без фильтрации строк фразой WHERE и с отсутствием преобразований столбцов (в то же время воспроизведение всех столбцов не обязательно). Есть и другие отличия, не востребованными в этом тексте.

Чтобы пользователь SCOTT имел доступ к данным, для каждой редакции требуется выдать отдельное разрешение:

Вот как этими разрешениями может воспользоваться SCOTT:

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

Упражнение. Отобрать у пользователя SCOTT привилегию на выборку данных из YARD.EMP_VIEW в редакции APP_RELEASE_1 и наблюдать результат попытки обращения.

Пример редакций процедур

Заведение разных редакций одной и той же процедуры в схеме со свойством EDITIONS_ENABLED = TRUE выглядит достаточно прозрачно. Так, для добавления данных о сотрудниках можно завести две редакции процедуры INSERT_EMPLOYEE следующим образом:

Откат транзакций сделан (а) чтобы сохранить прежние данные, и (б) в первом случае – чтобы закрыть транзакцию перед переключением на новую редакцию.

Пример редакций триггерных процедур

Теперь для добавления в БД данных о сотрудниках создадим две редакцмм триггерных процедур. Это делается аналогично обычным процедурам. Прикладной смысл триггерных процедур в данном случае состоит в нормализации имен сотрудников перед помещением в базу.

Обратите внимание, что для редактируемых представлений (EDITIONING VIEW) в триггерных процедурах не действует привязка к событию INSTEAD OF, как для обычных представлений, а вместо этого BEFORE и AFTER, как для основных таблиц. Это одно из проявлений особости редактируемых представлений от обычных.

Проверку можно выполнить следующей последовательностию команд в SQL*Plus:

Перекрестные триггерные процедуры для разных редакций

Когда отлаживается работа приложения с новой редакцией объектов БД, какое-то время обе редакции объектов (старая и новая) сосуществуют. Сложность в том, что работа с новой редакцией не должна портить данные, с которыми продолжает иметь дело старый вариант приложения. Если планируемые изменения в схеме однозначно взаимообратимы с исходным состоянием, помочь в этом способны перекрестные триггерные процедуры для разных редакций (межредакционные триггерные процедуры; crossedition triggers, CET).

Рассмотрим пример подготовки к изменению структуры таблицы EMP в схеме YARD. Предположим, требуется хранить в БД самостоятельно сведения о должностях, как например максимальную зарплату и тому подобное. Ради этого придется завести отдельную новую таблицу с данными о должностях, а в таблице EMP изъять столбец с названием должности сотрудника, и добавить заместо ссылку на сведения о должностях. Пока новая редакция приложения не будет объявлена основной, старый столбец придется какое-то время сохранять.

Подобное разбиение одной таблицы сотрудников на две – сотрудников и должностей – очевидно обратимо, так что на время отладки будет удобно воспользоваться межредакционными триггерными процедурами. Они будут отвечать при работе со старой редакцией за дублированное внесение изменений в новые структуры, а при работе с новой редакцией – в старые, обеспечивая в данных БД возможность предоставления «взгляда» на них как по-старому, так и по-новому.

Подготовка таблиц

Создадим таблицу должностей, добавим в таблицу сотрудников ссылку, при том что столбец с названием должности оставим до будущего перехода на новую редакцию приложения. Выполним в SQL*Plus:

Переименуем таблицу сотрудников, и отдадим ее старое имя двум редакциям представлений:

Создание перекрестных межредакционных триггерных процедур

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

Проверку способен организовать следующий код:

Как и раньше, если транзакция успела изменить какие-нибудь данные в БД, для настройки на новую редакцию ее потребуется сначала закрыть. В результате получим:

При работе со старой редакцией воспроизводится поведение старой таблицы EMP, а при работе с новой – с тою же таблицей, но в новом варианте.

Дополнительные замечания по технологии

Приведенные примеры перекрестных триггерных процедур были намерено упрощены. В жизни в них следовало бы предусмотреть реакцию на указание в качестве нового значения отсутствующей должности. Предположим, что в старом приложении подобная обработка не программировалась, то есть в БД добавлялась ровно то название должности, которае было указано в INSERT/UPDATE. Тогда для сохранения поведения старой реакции приложения следовало бы на возникающую в SELECT . INTO . FROM job ошибку NO_DATA_FOUND среагировать добавлением новой записи в таблицу JOB. Придется решить технический вопрос о поставке значений в JOBID; это может потребовать употребления генератора последовательности (sequence) и других усложнений.

При решении перейти на новую редакцию приложения перекрестные триггерные процедуры и редакционные представления данных следует удалить, а освободившееся имя EMP вернуть основной таблице:

Читайте также: