1

主題が私が達成しようとしていることを完全に伝えているかどうかはわかりませんが、説明させてください。

Oracleをストレージバックエンドとして使用するアプリケーションを構築しています。毎年、昨年のデータセットは「アーカイブ」され、新しいインスタンスが作成され、最初から入力されます。同じスキーマ内でこれを行うためのオプションは何ですか？

  1. バージョン情報をレコードレベルで保持します（これは、ユースケースには遅すぎると思われます）。
  2. バージョン情報をテーブルレベルで保持するため、新しいバージョンごとに、新しいバージョンプレフィックスを使用してすべてのテーブルを再作成します。（すべてコードで実行できるため、このソリューションが気に入っています）。
  3. ？

Oracleでこれを実現できるパーティション/パーソナリティ/名前空間のようなものはありませんか？

私のオラクルの経験はかなり限られています、どんな援助も大いに感謝されます！

4

4 に答える 4

1

RDBMS の概念モデルは、データの一時的なバージョンを維持するのにあまり適していません。したがって、この点で欠けているのはオラクルだけではありません。

バージョン情報をレコード レベルで保持するのが遅すぎると考える理由がわかりません。新しいバージョンの作成が遅すぎますか? または、通常の操作中にデータを取得するのが遅すぎませんか?

これがあなたがそれを行う方法です。CUSTOMER_REF のビジネス キーを持つテーブル CUSTOMERS を指定すると、通常は次のように作成できます (スペース上の理由から、ベスト プラクティスではなく省略構文を使用しています)。

create table customers 
( id number not null primary key
  , customer_ref number not null unique key
  , name varchar2(30) not null )
/

バージョン化された同等のものは次のようになります。

create table customers 
( id number not null primary key
  , customer_ref number not null 
  , version_number number
  , name varchar2(30) not null
  , constraint whatever unique (customer_ref, version_number) )
/

これは、VERSION_NUMBER の現在のバージョンを null のままにして、アーカイブ時にのみ入力することで機能します。ルックアップには を含める必要がありますand version_number is null。これは少し面倒で、作成する追加のインデックスに列を含める必要がある場合があります。

明らかに、すべてのバージョンのレコードを同じテーブルに保持すると、テーブルのサイズが大きくなり、パフォーマンスに影響を与える可能性があります。ここでは、Oracle のパーティショニング オプションが確実に役立ちます。また、来年の一連のデータを作成するための適切な方法も提供します。ただし、エンタープライズ ライセンスに追加料金がかかるため、高価なオプションです。 詳細をご覧ください。.

これで最も時間がかかるのは、新しいバージョンのテーブルで外部キーの関係を管理することです。合成主キーを使用することを選択したと仮定すると、アーカイブ プロセスは新しい ID を生成し、外部キーを参照する新しいバージョンの従属レコードにそれらを苦労してカスケードする必要があります。

このことを考えると、バージョンごとの目立たないテーブルは非常に魅力的に見えます。使いやすくするために、現在のバージョンにプレフィックスを付けないようにして、アーカイブが単純なプロセスになるようにします

create table customers_n as select * from customers;

バージョン対応表の作成中は、ダウンタイムを避けたい場合があります。その場合、具体化されたビューを使用して、アーカイブの切り替えまでの実行中にテーブルの状態をキャプチャできます。時計が 12 時を打ったら、リフレッシュをオフにすることができます。(注意: これはその場で考えているものです。私はこのようなことをしたことがないので、購入する前に試してください。)

複数のテーブル (およびパーティショニング) の適切な利点の 1 つは、アーカイブされたレコードを READ ONLY テーブルスペースに移動できることです。これは、不要な変更からそれらを保護するだけでなく、後続のバックアップからそれらを除外できることも意味します.

編集

アーカイブされたデータは時折修正される可能性があるとコメントしていることに気付きました。その場合、それを読み取り専用のテーブルスペースに移動することはうまくいきません。

于 2010-01-22T07:54:12.403 に答える
0

年ごとにスキーマが変更される可能性があります。たとえば、2010年には15列ありますが、2011年には16列目を追加します。その場合、同じアプリケーションが2010年と2011年の両方のデータで機能しますか。

スキーマが静的である場合は、「YEAR」列のあるテーブルに移動し、VPD / RLS/FGACを使用してYEAR=「2010」述語を適用します。

パフォーマンスに問題がある場合にのみ、パーティション分割について心配します。

于 2010-01-22T23:53:48.613 に答える
0

APC が言ったことに追加する唯一のことは、「名前空間」の要求に関することです。

Oracle の名前空間はスキーマであり、各スキ​​ーマで同じオブジェクト名を持つことができます。

もちろん、これはアプリが複数のバージョンにどのようにアクセスする必要があるかによって異なりますが、何らかの命名規則を使用して同じスキーマ内のテーブルのバージョンを維持する前に、年ごとに異なるスキーマに傾倒します。その理由は、最終的には悪夢を見るからです。少なくとも異なるスキーマでは、すべての DDL を同じにすることができ、オブジェクトへのすべての参照が同じになり、ER モデラーやクエリ ツールなどのツールがそのスキーマのコンテキスト内で機能します。データ モデルが変更されるため、ある時点でいくつかの比較ツールを実行する必要が生じる場合があります。すべてのテーブルに何らかのバージョン ポストフィックスが付いたファンキーな名前が付けられていると、うまく機能しません。

fromuser/touser または remap_schema オプションを使用して、スキーマをエクスポートまたはデータ ポンプですばやくコピー/移動できるため、新しいバージョンから昨年のデータをクリーンアップすることを除いて、多くのコードは必要ありません。

スキーマは「コンテナー」として非常に便利であり、私がホストするほとんどのアプリにはスキーマ レベルの権限しかありません。そのため、アプリをインスタンス間で簡単かつ迅速に移動したり、アプリの複数のコピーをサイドでホストしたりできることが保証されています。同じインスタンスのバイサイド。

于 2010-01-22T21:16:47.430 に答える
-1

1）年と行のいくつかの日付フィールドで間隔分割します。

2)各テーブルの最後に追加し、シーケンスとトリガーを入力します。

3)次に、この列の間隔年ごとに分割します。

于 2016-05-05T10:50:25.677 に答える