Как избежать прерывания запросов во временных таблицах после изменения 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», и вы можете одновременно запускать несколько версий этого представления в базе данных.

Другие вопросы по тегам