私はバックエンドとしてOracleを使用してJavaプロジェクトを作成しています。大量のデータを持つテーブルがいくつかあります。このデータは、6か月後に表をアーカイブするためにアーカイブされます。同じスキーマにあると同じスキーマまたは異なるスキーマのアーカイブテーブルについて
個別のユーザーオプションに基づいて、メインテーブルとアーカイブテーブルの両方からデータをフェッチする必要があることがあります。
どちらが優れたデザインですか？それぞれの利点は何ですか？私は2つの異なる製品で同様のシナリオでは動作し
おかげ
。私の意見では、同じスキーマに保管することが最善の方法ですが、パフォーマンスを向上させるには、異なる表領域のデータファイルを別々の物理ディスク（つまり、各表領域のSAN上の異なるLUN）に配置します。これは、データウェアハウスソフトウェアでこれを実現しています。アクティブなデータが入るテーブルと、1日の終わりにデータをHISTテーブルに移動する移動履歴プロシージャがあります。
異なるテーブルの構成以外の異なるスキーマの唯一のメリットは、異なるサーバー/インスタンスからスキーマを実行できるようにする場合です。特定のシナリオでは、テーブルに参加できるように思えますから、別のインスタンスに配置することはできません（DBLinkなしでは避けてください）。したがって、異なるスキーマを持つことの利点はあまりありません。
私はちょうどこのような何かをしたとカウンタJim's答えは実際には、別のスキーマのルートを好む。
いくつかの理由があります...
あなたは、あなたのテーブルに同じ名前を呼び出すことができます。それは有用で、何が起こっているのかを見るのは簡単です。スキンをarchiveと呼んだので、すべての選択はarchive.my_tableです。たとえば、
select * from prod.my_table
union
select * from archive.my_table
のように、2つのテーブルを結合する場合は、非常によく読み込まれ、明白です。
許可などのすべてのテーブル定義を取得して実行することができます。別の名前の新しい定義のロードを作成する必要はありません。唯一の違いは、元のスキーマがアーカイブスキーマから選択できる必要があることです。
異なる表スペースと異なるインデックス表スペースについてもJimと同意します（インデックス・テーブルスペースを使用している場合は索引付けする必要があります）。スピン・ディスクを使用している場合でも、より低速なディスクにアーカイブ表領域を置くことができます。ただし、問合せが少し遅くなるかどうかは関係ありません。