最初の質問は次のとおりです。そのデータをどうしますか？明確なビジネス要件がない場合は、それを行わないでください。
私は似たようなことをしました。3年間実行した後、「有効なデータ」の約20％があり、残りは「以前のバージョン」です。そしてそれは1000万+4000万レコードです。過去3年間に、変更の履歴を調査するための2つのリクエストがありましたが、どちらのリクエストもばかげていました。レコード変更のタイムスタンプを記録し、残業していないかどうかを確認するように依頼されました（午後5時以降）。
現在、誰も必要としないデータの80％を含む特大のデータベースで立ち往生しています。
編集：
あなたが可能な解決策を求めたので、私は私たちがしたことを説明します。検討しているソリューションとは少し異なります。
- すべてのテーブルには代理主キーがあります。
- すべての主キーは単一のシーケンスから生成されます。 Oracleは数値を生成してキャッシュできるため、これは正常に機能します。したがって、ここではパフォーマンスの問題は発生しません。 ORMを使用し、メモリ内の各オブジェクト（およびデータベース内の対応するレコード）に一意の識別子を持たせたいと考えました
- ORMを使用し、データベーステーブルとクラス間のマッピング情報は属性の形式です。
すべての変更は、次の列を持つ単一のアーカイブテーブルに記録されます。
- id（代理主キー）
- タイムスタンプ
- 元のテーブル
- 元のレコードのID
- ユーザーID
- トランザクションタイプ（挿入、更新、削除）
- varchar2フィールドとしてデータを記録する
- これは、フィールド名と値のペアの形式の実際のデータです。
物事はこのように機能します：
- ORMには、コマンドの挿入/更新と削除があります。
- 挿入/更新および削除コマンドをオーバーライドするすべてのビジネスオブジェクトに対して1つの基本クラスを作成しました
- insert / update / deleteコマンドは、リフレクションを使用してフィールド名/値のペアの形式で文字列を作成します。コードはマッピング情報を探し、フィールド名、関連する値、およびフィールドタイプを読み取ります。次に、JSONに似たものを作成します（いくつかの変更を追加しました）。オブジェクトの現在の状態を表す文字列が作成されると、アーカイブテーブルに挿入されます。
- 新しいオブジェクトまたは更新されたオブジェクトがデータベーステーブルに保存されると、そのオブジェクトはターゲットテーブルに保存されると同時に、現在の値を持つ1つのレコードがアーカイブテーブルに挿入されます。
- オブジェクトが削除されると、ターゲットテーブルからオブジェクトが削除されると同時に、トランザクションタイプが「DELETE」である1つのレコードがアーカイブテーブルに挿入されます。
プロ：
- データベース内の各テーブルにアーカイブテーブルはありません。また、スキーマが変更されたときにアーカイブテーブルを更新することを心配する必要もありません。
- 完全なアーカイブは「現在のデータ」から分離されているため、アーカイブによってデータベースのパフォーマンスが低下することはありません。別のディスク上の別のテーブルスペースに配置すると、正常に機能します。
- アーカイブを表示するための2つのフォームを作成しました：
- アーカイブテーブルのフィルターに従ってアーカイブテーブルを一覧表示できる一般的なビューアー。ユーザーがフォームに入力できるフィルターデータ（期間、ユーザーなど）。各レコードはフィールド名/値の形式で表示され、各変更は色分けされています。ユーザーは、各レコードのすべてのバージョンを確認でき、誰がいつ変更を加えたかを確認できます。
- 請求書ビューア-これは複雑でしたが、元の請求書入力フォームと非常によく似た請求書を表示するフォームを作成しましたが、異なる世代を表示できるいくつかの追加ボタンがあります。このフォームを作成するのにかなりの労力を要しました。フォームは数回使用されましたが、現在のワークフローでは必要なかったため、忘れられました。
- アーカイブレコードを作成するためのコードは、単一のC＃クラスにあります。データベース内のすべてのテーブルにトリガーを設定する必要はありません。
- パフォーマンスは非常に良好です。ピーク時には、システムは約700〜800人のユーザーによって使用されます。これはASP.Netアプリケーションです。 ASP.NetとOracleはどちらも、8GbRAMを搭載した1つのデュアルXEONで実行されています。
短所：
- 単一テーブルのアーカイブ形式は、データテーブルごとに1つのアーカイブテーブルがあるソリューションよりも読みにくいです。
- アーカイブテーブルの非IDフィールドの検索は困難です-
LIKEのみを使用できます 文字列の演算子。
したがって、もう一度、アーカイブの要件を確認してください 。これは簡単な作業ではありませんが、利益と使用は最小限に抑えることができます。