2

個人情報用のテンポラル テーブルがあるとします。

  • UUID (varchar)
  • main_document (varchar)
  • 名前 (varchar)
  • DoB (タイムスタンプ)
  • ジャンル (varchar)
  • アドレス (varchar)
  • 給与 (10 進数)

T1で、スキーマの移行を実行し、新しい列を追加します。これ以降、テーブルには次のものがあります。

  • UUID (varchar)
  • main_document (varchar)
  • 名前 (varchar)
  • DoB (タイムスタンプ)
  • ジャンル (varchar)
  • アドレス (varchar)
  • 給与 (10 進数)
  • 電子メール(varchar)*

次に、T2で別のスキーマ移行を実行し、main_document のデータ型を NUMBER に変更します。

  • UUID (varchar)
  • メインドキュメント (数字) *
  • 名前 (varchar)
  • DoB (タイムスタンプ)
  • ジャンル (varchar)
  • アドレス (varchar)
  • 給与 (10 進数)
  • 電子メール (varchar)

次に、T3で別のスキーマ移行を実行し、ジャンル列を削除します

  • UUID (varchar)
  • main_document (数値)
  • 名前 (varchar)
  • DoB (タイムスタンプ)
  • --------------- *
  • アドレス (varchar)
  • 給与 (10 進数)
  • 電子メール (varchar)

次に、T4で別のスキーマ移行を実行し、ジャンル列を追加しましたが、データ型は NUMBER になりました。

  • UUID (varchar)
  • main_document (数値)
  • 名前 (varchar)
  • DoB (タイムスタンプ)
  • ジャンル (数字) *
  • アドレス (varchar)
  • 給与 (10 進数)
  • 電子メール (varchar)

T1、T2、T3、T4 などでスキーマが変更された場合、DB にクエリを実行する方法 (時間をさかのぼる) はありますか?

同様に、私たちは (壁の時間) T4 にいて、次を実行します: select * from people AS OF T3 , 何を返す必要がありますか? 本当にタイムトラベル？

これらのテンポラル テーブル + スキーマの移行でこの複雑さをすべて回避するためのベスト プラクティスまたは戦略はありますか?

どんな助けでも大歓迎です。

ありがとう

4

1 に答える 1