Как стать автором
Обновить

Организация хранения исторических данных в Oracle

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров5.2K
Всего голосов 18: ↑16 и ↓2+18
Комментарии7

Комментарии 7

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

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

"... О способах организации хранения ..." - ожидал что-то про SCD минимум, а тут этот термин даже не упоминается, а вместо этого про триггеры...

Для больших объемов хороший способ - накапливать события for-each-row-триггером, а по завершению отправлять балком в таблицу истории с помощью statement-триггера.
Преимущества: быстро.
Недостаток: 2 триггера

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

НЛО прилетело и опубликовало эту надпись здесь

Только мне показалось, что графики для 1000 и 100000 строк полностью одинаковые (цифры-то точно те же самые)?

Читал по диагонали, и не увидел обсуждения того, что флешбек по сути никому не прдходит, потому что кроме знания что изменилось надо знать еще и кем. А если у вас аппсервер то вы узнаете только ораклового пользователя, от которого все вызовы и делаются. При этом не рассмотрены oracle change datacapture и oracle streams, внешние вызовы (и надо не забыть, что если был откат транакции то такие изменения не интересны) и тп включая внешние утилиты анализа архивлогов.

Кроме того, на триггерах можно и ддл операции сделать и сделать инвариантными логи к ддл.

Короче не понял для чего статья. так это и в постгресе можно проделать и даже в мускуле

Зарегистрируйтесь на Хабре, чтобы оставить комментарий