0

更新時にリンクされたデータ エンティティの整合性を維持するためのベスト プラクティスは何ですか?

私のシナリオ

  1. 「クライアントと請求書」という 2 つのエンティティがあります。[クライアントは定義であり、請求書はトランザクションです]。
  2. 多くの請求書をクライアントに発行した後、クライアント情報を変更する必要がある場合があります。たとえば、「請求先住所/場所が変更された、または会社名が変更された...など」などです。
  3. システム内のデータの整合性を保つために、ユーザーがクライアント情報を更新できる必要があるのは普通のことです。
  4. 請求書の「トランザクション エンティティ」には、クライアント ID だけでなく、「クライアント名、住所、連絡先」などの請求書に関連するすべてのクライアント情報も保存します。これは、トランザクション エンティティにデータを保存するためのよく知られた方法です。
  5. ユーザーが新しい請求書を作成した場合、新しいクライアント情報は、同じクライアント ID とともに請求書レコードに保存されます (非常に明白です!)。

私の質問

  1. 挿入と更新のために異なる場所からデータ エンティティ "クライアント" をバインドしても問題ありませんか? [説明: ステップ 1 ～ 4 のアプローチに従った場合、新しい請求書を作成する場合はクライアント テーブルからクライアント エンティティをバインドする必要がありますが、請求書を更新/印刷する場合は、請求書テーブルからクライアント エンティティをバインドする必要があります。そうしないと、データは一貫性がなく、整数にもなりません...では、データ バインディングのこのカスタム要件を処理するために、DAL でスパゲッティ コードを作成せずにデータの整合性を維持するにはどうすればよいでしょうか??]
  2. 「すべてのバージョンの履歴を保持する」更新前にエンティティ データの以前のバージョンをすべて保存していたシステムを通過しました。カスタムバインディングを回避するために同じ方法を使用したい場合、データベース設計「MySQL の使用」に関してこれを行うにはどうすればよいですか? [説明: 一部の請求書はバージョン 1.0 のクライアントで作成され、その後クライアント情報が更新され、バージョンが 1.1 になり、新しい請求書は最新のバージョンで作成されました...では、この方法に従ってよいのでしょうか? また、エンティティのバージョン管理とバインディングの要件を満たすには、エンティティ/テーブルをどのように設計すればよいですか?
  3. 私を正しい方向に導くことができる本や参考文献を提供してください。

ありがとう、

4

3 に答える 3

1

あなたがする必要があるのは、テーブルをそのままにしておくことです。おっしゃるとおり、商品の発送先の履歴のために、請求書に顧客情報を保存する必要があります。変更された場合、まだ発送されていない請求書を除いて、この情報を更新しないでください。このタイプの情報を維持するには、出荷されていない請求書を検索し、それらの住所を自動的に更新するトリガーが顧客テーブルに必要です。

クライアント情報の履歴バージョンを保存する場合、正しいプロセスは、監査テーブルを作成し、トリガーを介してデータを入力することです。

この場合のデータの整合性は、顧客 ID への外部キーを使用するだけです。ID 自体は決して変更したり、ユーザーによる変更を許可したりしてはならず、整数などの代理番号にする必要があります。実際の請求書の住所情報を変更してはならないため (発送されていない場合は変更したほうがよい場合を除きます。そうしないと、製品が間違った場所に発送されてしまいます)、データの整合性を維持するにはこれで十分です。これにより、物が実際に出荷された場所を確認できますが、外部キーを使用してクライアントに関する現在の情報を検索することもできます。

変更するクライアント (他社に買収された企業) がある場合は、サーバー上でプロセスを実行して古いレコードの顧客 ID を更新するか、現在の親 ID に属するクライアント ID を示すテーブル構造を作成することができます。最初の方法は、何百万ものレコードを変更することについて話していなければ、簡単に実行できます。

于 2010-01-25T16:15:04.020 に答える
0

「これは、どこに出荷されたかの履歴記録を保持するためにデータを非正規化する必要があるビジネスケースです。彼の設計は正しくありません。」

これを新しい応答として追加して申し訳ありませんが、[コメントを追加]ボタンが表示されません。

「彼のデザイン」は確かに間違っていません...それは正規化されているからです!!!

請求書に対応する住所が機能的に顧客IDのみに依存しているとは限らないため、正規化されています。

だから：正規化、はい私はそう思います。ここで関係する問題は、正規化だけではありません。

于 2010-01-26T19:01:29.787 に答える
-3

あなたが何を目指しているのかは完全にはわかりませんが、リレーショナル データベースと SQL に関する多くの本で利用できる正規化について読みたいと思います。最終的には、外部キーで接続された 2 つのテーブルになると思いますが、前の文を調べてみると、考えを明確にするのに役立つかもしれません。

于 2010-01-24T16:23:46.733 に答える