Концептуальная модель RDBMS не очень хороша для поддержки временных версий данных. Так что в этом отношении не только Oracle.
Мне неясно, почему вы думаете, что хранение информации о версии на рекордном уровне будет слишком медленным. Слишком медленно в создании новой версии? Или слишком медленно, когда дело доходит до извлечения данных во время обычных операций?
Вот как ты мог это сделать. Учитывая таблицу CUSTOMERS с бизнес-ключом CUSTOMER_REF, я мог бы, как правило, построить ее следующим образом (я использую сокращенный синтаксис, а не передовой опыт из-за недостатка места):
create table customers
( id number not null primary key
, customer_ref number not null unique key
, name varchar2(30) not null )
/
Версионный эквивалент будет выглядеть так:
create table customers
( id number not null primary key
, customer_ref number not null
, version_number number
, name varchar2(30) not null
, constraint whatever unique (customer_ref, version_number) )
/
Это работает, сохраняя текущую версию VERSION_NUMBER нулевой, и заполняя ее только во время архивирования. Любой поиск должен включать and version_number is null. Это будет немного болезненно, и вам может понадобиться включить столбец в любые дополнительные индексы, которые вы создаете.
Очевидно, что поддержание всех версий записей в одной таблице приведет к увеличению размера ваших таблиц, что может повлиять на производительность. Опция Oracle Partitioning может определенно помочь здесь. Это также даст вам аккуратный способ создания набора данных следующего года. Тем не менее, это дополнение к корпоративной лицензии за дополнительную плату, поэтому это дорогой вариант. Узнайте больше. .
Наиболее трудоемким аспектом этого будет управление связями внешних ключей в новой версии таблицы. Предполагая, что вы решите использовать синтетические первичные ключи, процесс архивирования должен будет сгенерировать новые идентификаторы, а затем кропотливо каскадировать их в зависимые записи в новых версиях ссылок на внешние ключи.
Если подумать об этом, отдельные таблицы для каждой версии кажутся очень привлекательными. Для простоты использования я бы оставил текущую версию без префикса, чтобы архивирование стало просто процессом
create table customers_n as select * from customers;
Возможно, вы захотите избежать простоев при создании версионных таблиц. В этом случае вы можете использовать материализованные представления для захвата состояния таблиц во время подготовки к переключению архивирования. Когда часы бьют двенадцать, вы можете отключить обновление. (предостережение: это мысли на лету, я никогда не делал ничего подобного, поэтому попробуйте, прежде чем купить.)
Одним из важных преимуществ нескольких таблиц (и разбиения) является то, что вы можете перемещать архивированные записи в табличное пространство READ ONLY. Это не только предохраняет их от нежелательных изменений, но также означает, что вы можете исключить их из последующих резервных копий.
редактировать
Я заметил, что вы прокомментировали, что архивные данные могут периодически изменяться. В этом случае перемещение его в табличные пространства READ ONLY не является правильным.