Oracle, ведение истории изменения данных

← →
bissoft (2010-09-15 22:25) [0]

Итак, есть относительно большая система, состоящая из клиентских приложений и базы данных oracle 10. Стоит задача хранить историю изменения данных. То есть, у пользователей иногда возникают вопросы - вот неделю назад тут в документе стояло десять тысяч рублей, а теперь стоит двадцать тысяч, что за нафиг? Нужно разобраться кто и когда менял эти данные. Вполне вероятно, это в какой-то степени задача клиентского ПО - вести историю данных, но возможности реализовать это нету, было решено делать универсально со стороны базы данных. Наше решение:

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

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

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

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

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

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

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

P.S. Фактически, такая система слежения будет достаточно универсальна и не завязана на какой-то конкретный проект. Это просто система, позволяющая отслеживать изменение данных в базе данных oracle. У нас из специфики будет только одно - хранение ID"шки пользователя, который меняет данные, мы будем это получать своим способом, поскольку у нас есть своя система аутентификации (на самом деле там еще звено в виде сервера приложение, но это уже лирика...) и сохранение аккаунта входа в oracle ничего не скажет, сотни пользователей могут работать под одним Oracle-аккаунтом.
В связи с этим вполне возможно на рынке есть готовые приложения, которые осуществляют данную задачу. Было бы интересно посмотреть.

← →
bissoft (2010-09-15 22:25) [1]

Допустим, что мы видим из подводных камней:

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

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

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

← →
Дмитрий Тимохов (2010-09-15 23:54) [2]

Зачем возлагать это на СУБД, если есть сервер приложений?
Напрямую же клиенты с БД не работают, только через СП? Или работают напрямую?

← →
bissoft (2010-09-16 08:47) [3]

> Зачем возлагать это на СУБД, если есть сервер приложений?

каким образом это можно возложить на сервер приложений?

Распарсивать передаваемый ему текст SQL-запроса?!?! А откуда узнать старые данные для сохранения? Вытаскивать из текста SQL-запроса новые данные? Это как раз чересчур сложная, имхо, задача.

← →
12 © (2010-09-16 09:03) [4]

велосипед, конечно

не dba, но на его месте начал бы с
http://www.google.ru/webhp?rls=ig#num=20&hl=ru&newwindow=1&rls=ig&q=oracle+%D0%B0%D1%83%D0%B4%D0%B8%D1%82&aq=f&aqi=g1&aql=&oq=&gs_rfai=&fp=67bc4258aacbfe4d

← →
Дмитрий Тимохов (2010-09-16 09:22) [5]

> bissoft (16.09.10 08:47) [3]
>
>
> > Зачем возлагать это на СУБД, если есть сервер приложений?
>
>
> каким образом это можно возложить на сервер приложений?

ну понял, он просто транслирует запросы от клиентов к БД, а не генерит их сам на основе команд клиентов (удаленных вызовов).
тогда да, СП не подойдет.
тады не знаю )

← →
Sergey13 © (2010-09-16 10:03) [6]

> [0] bissoft (15.09.10 22:25)

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

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

В Оракле помнится был ЛогМайнер и вроде еще какая то СТАНДАРТНАЯ штука (вспоминая прошлые обсуждения этого вопроса, вроде даже ИШ про это рассказывал) с помощью которых можно докопаться практически до любых хронологий изменений. Так что городить свои смысла, по моему, нет.

← →
Kerk © (2010-09-16 10:10) [7]

> bissoft (15.09.10 22:25) [1]
> Внесли изменение в таблицу, внесли изменение в клиентское
> ПО, сделали скрипт обновления структуры для обновления до
> новой версии ПО.
> А вот дублирующую таблицу изменить забыли. В результате
> триггер исторический может начать плеваться exception и
> застопорить вставку, обновление и удаление данных.

А в чем проблема? Такое заметит сам программист, оно даже до тестеров скорее всего не дойдет.

← →
Игорь Шевченко © (2010-09-16 11:12) [8]

RTFM: Oracle workspace management

← →
Игорь Шевченко © (2010-09-16 11:13) [9]

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

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

← →
bissoft (2010-09-16 16:14) [10]

> А в чем проблема? Такое заметит сам программист, оно даже
> до тестеров скорее всего не дойдет.

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

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

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

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

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

← →
Sergey13 © (2010-09-16 16:32) [11]

> [10] bissoft (16.09.10 16:14)
> > Вместо нормальной работы по контролю доступа, разграничению
> > прав и проработки бизнес логики предлагается глобальная шняга
>
> это имеет крайне посредственное отношение к разграничению
> доступа и правам. Человек вполне может иметь права сделать
> ДЕЙСТВИЕ, но это не отменяет задачи при наличии желания
> узнать КТО конкретно сделал этот действие.

Зато имеет непосредственное отношение к бизнес логике, а уже на этом фоне и к правам.
Если КТО УГОДНО может ЧТО УГОДНО менять в ПОДПИСАННОМ документе, то этот бардак логами не спасешь. Если все нормально, но нужна история изменения - значит система просто недоработана. Причем именно в этом месте, а не вообще. Если это криминал и все заменили не просто так, то скорее всего подобные логи можно обойти всякими програмистско-ДБАшными штучками.
ИМХО.

← →
Игорь Шевченко © (2010-09-16 18:01) [12]

> Если это криминал и все заменили не просто так, то скорее
> всего подобные логи можно обойти всякими програмистско-ДБАшными
> штучками.

Можно сделать так, что факт обхода будет зафиксирован. Иногда и этого достаточно

← →
bissoft (2010-09-16 20:49) [13]

> Если КТО УГОДНО может ЧТО УГОДНО менять в ПОДПИСАННОМ документе,
> то этот бардак логами не спасешь

ты придумываешь ситуацию, а потом ее критикуешь. Почему кто угодно что угодно?

Нет, есть определенный круг лиц, кто имеет доступ. Они ДОЛЖНЫ иметь доступ. Но это КРУГ лиц. Реальность такова, что потом весь этот допущенный круг лиц утверждает, что они ничего не меняли. Ооочень часто это бывает в виде "Мы ничего не меняли, это программисты программу плохую сделали". Потом приходится тыкать пальцем, что вот конкретно этот человек в это время изменил эти данные, это практика.

← →
Игорь Шевченко © (2010-09-16 21:40) [14]

bissoft (16.09.10 20:49) [13]

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

← →
bissoft (2010-09-16 23:49) [15]

Игорь Шевченко, читаю, разбираюсь...

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

Аудит с помощью Oracle workspace management VS ручной аудит на триггерах?
Для какой системы чтобы лучше подошло, из опыта?

← →
Игорь Шевченко © (2010-09-17 00:16) [16]

> Аудит с помощью Oracle workspace management VS ручной аудит
> на триггерах?

навскидку workspace manager недоступен на oracle standard edition, а триггеры доступны везде. С другой стороны workspace manager подерживает реальную версионность данных, а триггеры - только аудит. Триггеры таки можно отключить, если очень постараться, даже с защитой от отключения (на триггерах системных событий). Но следы при этом останутся, так что будет кого спрашивать.

← →
старый маразматик (2010-09-17 02:24) [17]

> Игорь Шевченко © (17.09.10 00:16) [16]

> Триггеры таки можно отключить, если очень постараться

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

> bissoft (15.09.10 22:25)

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

← →
Рамиль © (2010-09-17 09:41) [18]

В нашей ERP (в смысле работаем в ней, а не разрабатываем), например, сделана одна таблица. Насколько помню, туда записывается время, таблица в которой произошло изменение, пользователь, тип операции (upd, del, ins) и в блоб вся запись перед изменением в каком то своем формате.
+ одна таблица, ничего менять не надо.
- наверное, медленнее.

← →
bissoft (2010-09-17 10:22) [19]

> + одна таблица, ничего менять не надо.
> - наверное, медленнее.

основной недостаток такого подхода - нет возможности грамотной выборки, фильтрации и сортировки.

← →
Рамиль © (2010-09-17 10:33) [20]

> основной недостаток такого подхода - нет возможности грамотной
> выборки, фильтрации и сортировки.

А это так часто и быстро нужно? Таблица и примерная дата обычно известна.
Зато откат изменений удобно делать.

← →
Игорь Шевченко © (2010-09-17 10:40) [21]

старый маразматик (17.09.10 02:24) [17]

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

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

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

Можешь сам покраситься и выброситься, а можешь матчасть почитать - трындежа всяко меньше будет

← →
Sergey13 © (2010-09-17 12:13) [22]

> [13] bissoft (16.09.10 20:49)
> ты придумываешь ситуацию, а потом ее критикуешь. Почему кто угодно что угодно?

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

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

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

Ты же за имхами сюда пришел? Вот и пользуйся. 8-)

Я делал подобный аудит на тригерах. После полугода эксплуатации объем данных аудита на порядок превзошел объем собственно данных. Тормозов особых не было, но думаю, что до них просто не дошло. За это время было одно или два "разбирательства" по поводу "там вчера другое было", которые закончились словами "внимательнее, Маша, надо быть". И фсе. Подумал я про это на досуге - и отключил нахрен. 8-)
Это не аргумент для делать/не делать. Это просто иллюстрация моей имхи.

← →
bissoft (2010-09-17 12:54) [23]

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

Насчет объема - да, предусматриваем систему скидывания данных в дамп, архивация и на полку.

← →
Sergey13 © (2010-09-17 13:05) [24]

> [23] bissoft (17.09.10 12:54)
> мы софтверная фирма. Заказчик хочет это и платит за это деньги.

С этого бы и начал. Тогда разумеется надо делать! 8-)

← →
старый маразматик (2010-09-18 04:41) [25]

> Игорь Шевченко © (17.09.10 10:40) [21]

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

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

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

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

> Sergey13 © (17.09.10 12:13) [22]

> объем данных аудита на порядок превзошел объем

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

← →
Sergey13 © (2010-09-20 11:52) [26]

> [25] старый маразматик (18.09.10 04:41)
> а почему стандартный ораклевый аудит не включили?

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

старый маразматик (18.09.10 04:41) [25]

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

Ты даже мой пост не хочешь читать.

← →
старый маразматик (2010-09-21 21:56) [28]

> Игорь Шевченко © (20.09.10 17:53) [27]

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

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

> Sergey13 © (20.09.10 11:52) [26]

10 лет назад уже тырнета была, ну, хотя и тормознутая. но была. 2000 году. вот, ежели 20 лет назад(или немного меньше)... там тоже чего-то было, как оно называлось не помню, но, увы, приобщится не удалось.

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

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

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

старый маразматик (21.09.10 21:56) [28]

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

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

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

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

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

Впрочем, все это можно в доке по ораклу прочитать, там более подробно и с картинками написано.

← →
старый маразматик (2010-09-21 23:47) [30]

> Игорь Шевченко © (21.09.10 23:01) [29]

> Владелец - это тот, кто создал объект

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

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

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

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

ну нет, зачем же тогда вся эта система предусмотрена? естественно ничего не увидит и не сможет. почему я и как-то твою первую цидулину странно понял.

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

> [28] старый маразматик (21.09.10 21:56)
> 10 лет назад уже тырнета была

А я и не говорю, что его не было как класса. Я говорю, что у меня (у нас в конторе) 10+ (+ это значит больше) лет назад его или не было совсем или был дайлап 28к деленный человек на 10-12 по 2-3 часа в день. Конкретнее не помню.

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

а почему вообще возможна правка в документе, а не черновике? Если документ разнесен, то правок допускать нельзя. И если вдруг в платеже вместо 10 появилось 20, то смотреть разноски и кто их сделал.

← →
старый маразматик (2010-09-22 22:02) [33]

> Sergey13 © (22.09.10 10:30) [31]

> был дайлап

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

> Думкин © (22.09.10 10:36) [32

> а почему вообще возможна правка в документе

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

> то смотреть разноски и кто их сделал

дык, к тому в оракле и есть система аудита(а вот на кого напускать - это админ таки решает). и никто не уйдет обиженным(с)тыренно

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

Это я понимаю, но англичане ружья кирпичом не чистят. Это статья есть такая, по поводу правок в отработанном. :)

← →
старый маразматик (2010-09-23 22:05) [35]

Удалено модератором

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

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

После завершения тестирования запускаются те же скрипты (уже проверенные) и происходит перенос в боевую схему - с которой и работают конечные юзеры.

> В БД есть 3 схемы - девелоперская, тестовая и боевая.

У нас так и для кода и для БД. Сама структура приложения такая, что это все идет одной связкой.

Oracle, ведение истории изменения данных Найти похожие ветки