0

Oracle バックエンドを使用してエンタープライズ アプリケーションを開発しています。現在、DB アーキテクチャのコア部分を設計していますが、いくつか質問があります。

  1. まず最も重要なことは、私のテーブルのほとんどは古いデータを保持する必要があるということです。例えば

フィールドを持つテーブルを検討してください

契約番号、契約名、契約者、契約メール

私は次のような記録を持っています

12、xxx、yyy、xxx@zzz.ccc

そして、誰かがそれを変更します

12、xxx、zzz、xxx@zzz.ccc

古いレコードのコピーを保持しながら、いつでも新しいレコードを表示する必要があります。

だから私が考えたのは、古いデータの重複レコードを入れて、変更されたフィールドを更新し、「アクティブ」のようなものでアクティブなレコードを追跡するためのフラグを1にすることでした.

欠点は、これによりテーブルに冗長性が生じ、悪い設計のように見えることです。しかし、他のモデルは不必要に複雑に思えますが、これは私にはすっきりしているように思えます。また、重複したレコードを持つパフォーマンスの問題も見当たりません。それで、これでいいのか、それとも何か足りないのか教えてください。

  1. 1対多の関係がある場合、各レコードでマスターIDを繰り返し、子IDを変更することにより、個々のレコードに複数のエンティティをマップするマッピングテーブルがあると想定しています。これは正しい方法ですか、それとももっと良い方法がありますか。

  2. データベースのベスト プラクティスに関する本はありますか。

ありがとう。

扱っているデータベースは、2 ノード RAC クラスタ上の Oracle 11g です。

4

2 に答える 2

1

古い/履歴レコードを別のテーブルに保存します。upd / delトリガーを作成して、監査/履歴テーブルにデータを入力し、メインテーブルに最新のデータのみを保持します。

例については、こちらをご覧ください。他の多くの同様の例がSOに存在します。

于 2012-07-12T11:13:40.073 に答える
1

また、重複したレコードを持つパフォーマンスの問題も見当たりません。

時間の経過とともに 15 回の更新がある行があるとします。テンポラル データを保存しない場合 (異なるバージョンの行を保存しない場合)、最終的に 1 つの行を保存することになります。テンポラル データを格納すると、最終的に 15 行を格納することになります。

ID 番号だけでは 1 つの行を識別するのに十分ではないため、さらに多くのインデックスも必要です。

比較的小さなテーブルしかない場合、おそらくパフォーマンスの違いは見られません。ただし、 1,000 万行のテーブルと1 億 5,000 万行のテーブルのパフォーマンスは異なります。(1 行あたり 15 バージョン、× 1000 万行。)

1対多の関係がある場合、各レコードでマスターIDを繰り返し、子IDを変更することにより、個々のレコードに複数のエンティティをマップするマッピングテーブルがあると想定しています。これは正しい方法ですか、それとももっと良い方法がありますか。

おそらく、どの子行がどの親行に属しているかを知る必要があります。そのため、キーには複数のマスター ID が必要です。マスター ID だけでは、親テーブル内のその行のどのバージョンが特定の子行に適用されるかはわかりません。

データベースのベスト プラクティスに関する本はありますか。

テンポラル データベースに関する本があります。私が最初に知ったのは、Snodgrass のDeveloping Time-Oriented Database Applications in SQLです。いくつかの形式で利用でき、無料です。これも少し古いですが、テンポラル データベースを構築する場合は、その中の情報を理解することが重要です。また、Date の著書「Temporal Data and the Relational Model 」を読んでみてください。

ウィキペディアには、テンポラル データベースの背後にある考え方をまとめた記事があります。

正規化は完全に必須です。

それは無意味な質問です。2NF に正規化されたテーブルでは、5NF または 6NF に正規化されたテーブルとは異なる問題が発生します。

于 2012-07-12T10:33:05.963 に答える