Как избежать прерывания запросов во временных таблицах после изменения SCHEMA?
Представьте, что у меня есть временная таблица для личной информации:
- UUID (varchar)
- main_document (varchar)
- имя (варчар)
- Дата рождения (отметка времени)
- жанр (варчар)
- адрес (varchar)
- зарплата (десятичная)
в T1 я запускаю миграцию схемы и добавляю новый столбец, теперь в таблице есть:
- UUID (varchar)
- main_document (varchar)
- имя (варчар)
- Дата рождения (отметка времени)
- жанр (варчар)
- адрес (varchar)
- зарплата (десятичная)
- ЭЛЕКТРОННАЯ ПОЧТА (varchar)*
Затем в T2 я запускаю еще одну миграцию схемы и меняю тип данных main_document на NUMBER.
- UUID (varchar)
- основной_документ ( ЧИСЛО )*
- имя (варчар)
- Дата рождения (отметка времени)
- жанр (варчар)
- адрес (varchar)
- зарплата (десятичная)
- электронная почта (varchar)
Затем в T3 я запускаю еще одну миграцию схемы и удаляю столбец жанра.
- UUID (varchar)
- main_document (номер)
- имя (варчар)
- Дата рождения (отметка времени)
- ---------------*
- адрес (varchar)
- зарплата (десятичная)
- электронная почта (varchar)
Затем в T4 я запускаю еще одну миграцию схемы и добавляю столбец жанра, но теперь он имеет тип данных NUMBER.
- UUID (varchar)
- main_document (номер)
- имя (варчар)
- Дата рождения (отметка времени)
- жанр (ЧИСЛО) *
- адрес (varchar)
- зарплата (десятичная)
- электронная почта (varchar)
Как я могу запросить свою БД (возвращаясь назад во времени), если схема изменилась на T1, T2, T3, T4 и т. д.?
Мол, мы на (время стены) Т4 и запускаем: select * from people AS OF T3, что надо вернуть? Это действительно путешествие во времени?
Существуют ли какие-либо передовые методы или стратегии, позволяющие избежать всей этой сложности с этими темпоральными таблицами и миграцией схемы?
Любая помощь приветствуется.
Спасибо
1 ответ
Я бы порекомендовал вам взглянуть на концептуальный документ по переопределению на основе издания (EBR):
https://www.oracle.com/a/tech/docs/ebr-technical-deep-dive-overview.pdf
Даже если вы не планировали использовать EBR, вы получите представление о том, как выполняется миграция схемы, при этом позволяя просматривать схему в различные моменты ее истории.
Короче говоря, таблица представляет ВСЕ временные состояния данных, а представления представляют моменты времени. Таким образом, взяв гораздо более простой пример:
Time 1: Table is ID, NAME, GENDER
Time 2: Table is ID, NAME, DATE_OF_BIRTH
Затем таблица содержит все атрибуты со всех временных шкал, т.е.
ID, ИМЯ, ПОЛ, ДАТА_РОЖДЕНИЯ_РОЖДЕНИЯ
и вы используете представления для управления временным представлением данных, например
VIEW1: select ID, NAME, GENDER from TABLE
VIEW2: select ID, NAME, DATE_OF_BIRTH from TABLE
Преимущество EBR заключается в том, что он позволяет вызывать как «view1», так и «view2» (скажем): «MY_VIEW», и вы можете одновременно запускать несколько версий этого представления в базе данных.