1

メッセージとコントラクトがあります。メッセージは多くのコントラクトと共に送信され、コントラクトは複数のメッセージに属することができます。これは単純な多対多の関係ではありません。

  • 契約にはステータスがあります。各メッセージの契約ステータスを追跡する必要があります。また、契約の開始日と終了日はビジネス ロジックに基づいて変更でき、各メッセージにはそれらの値のバージョンが必要です。

  • 契約当事者は ContractID のみに依存し、メッセージごとに変更されることはありません。

したがって、私はERDを次のように作成しました:-

契約

  • 契約ID
  • 最初のパーティ
  • セカンドパーティ
  • 承認日

メッセージ

  • メッセージ ID
  • メッセージ日付

メッセージコントラクト

  • 契約ID
  • メッセージ ID
  • 契約状況
  • 契約開始日
  • 契約終了日

多対多の関係には、より複雑なロジックが必要です。Contract 列を MessageContract に移動して、Contract テーブルを削除することはできますか? 非正規化の原則により、それが可能になりますか?

コントラクト テーブルは、これら 3 つの列を保持するためにのみ使用されます。MessageContract 以外の他のテーブルとの関係はありません。MessageContract に配置する前にコントラクトを選択する必要があります。20,000 件のメッセージがあるため、これを頻繁に行います。一日あたり。良好なスループットを得るには、すべてのプロセッサ サイクルが必要です。コントラクトが新しいテーブルと新しい関係を持っている場合のスケーラビリティが心配です。新しいテーブルを配置する理由がわかりませんが、システムが稼働中で、新しいテーブルを追加する必要がある場合はどうでしょうか。この場合の良い習慣は何ですか。

4

1 に答える 1

1

1 日あたり 20,000 件のメッセージがあるので、あなたのラップトップはこの負荷に耐えられると思います。この要求の厳しい体制では、パフォーマンスについてあまり心配する必要はありません。

データを正規化することには、書き込みの高速化やバグのリスクの軽減など、多くの利点があります。

また、ビジネスロジックに基づいて契約開始日と終了日を変更できます

契約テーブルをインライン化すると、多くの場所でこれらの日付を更新する必要があります。これは、より多くの開発作業であり、遅く、バグの可能性が高くなります。これが正規化の主要な議論です。

コントラクトが新しいテーブルと新しい関係を持っている場合のスケーラビリティが心配です。

契約との新しい関係を追加すると、正規化されたアプローチがさらに魅力的になります。契約データを他の複数のテーブルにインライン化する必要はありません。

非正規化も有効な手法ですが、あなたのケースには当てはまらないと思います。

正規化されたデータ モデルから始めて、適切にインデックスを作成し、簡単なパフォーマンス テストを行うことをお勧めします。すべてがうまくいっていることがわかるでしょう。

于 2013-07-14T11:19:31.293 に答える