3

私が以下に提供した情報に基づいて、別々のテーブルを異なるタイプの契約を保持する1つのテーブルに非正規化するのが良い考えかどうかについてあなたの意見を教えてください？..賛否両論は何ですか？..誰かがこれを試みましたかbefore？..銀行システムはCIF（顧客情報ファイル）[マスター]を使用します。顧客はさまざまな種類の口座、CD、住宅ローンなどを持ち、トランザクションコード[種類]を使用しますが、それらを1つのテーブルに保存しますか？

ローン、購入、販売のトランザクション用に別々のテーブルがあります。これらの各テーブルの行は、次の方法で対応する顧客に結合されます。

customer.pk_id SERIAL = loan.fk_id      INTEGER; 
                      = purchase.fk_id  INTEGER; 
                      = sale.fk_id      INTEGER;

これらのテーブルには、ポーン、購入、販売という同じ商品を中心に展開する共通のプロパティが非常に多いため、これらを「契約」という1つのテーブルに統合して実験し、次の列を追加しました。

Contracts.Type char(1) {L=Loan, P=Purchase, S=Sale}

シナリオ：

顧客は最初に商品をポーンし、2回の利息を支払い、次にその商品を質屋に販売することを決定します。質屋は商品を在庫に入れ、最終的に別の顧客に販売します。

たとえば、次のような汎用テーブルを設計しました。

Contracts.Capital DECIMAL(7,2)

ローン契約では、ポーンの元本を保持し、購入では購入価格を保持し、販売では販売価格を保持します。

このデザインは良いアイデアですか、それとも別々に保つ必要がありますか？

4

2 に答える 2

4

テーブルの2番目の設計の方が優れており、「正規化」されています。

あなたの最初のデザインは非正規化されたものでした！

基本的に、「サブタイプ/スーパータイプ」と呼ばれるデータベース設計/モデリングパターンに従って、多くの共通データと各トランザクションタイプに固有のデータが存在するトランザクションなどを処理します。

これをモデル化するための2つの受け入れられた方法があります。変数データが​​最小の場合、トランザクションタイプ固有の属性が「null許容」列に保持されている単一のテーブルにすべてを保持します。（これは本質的にあなたのケースであり、あなたは正しいことをしました！）

もう1つのケースは、「珍しい」データがトランザクションタイプによって大きく異なる場合です。この場合、すべての「共通」属性を保持するテーブルと、その「タイプ」の「珍しい」属性を保持する各タイプのテーブルがあります。 。

ただし、「ローン」、「購入」、「販売」は取引として有効です。Inventoryは別のエンティティであり、独自のテーブルが必要だと思います。基本的に、「ローン」は在庫トランザクションに追加され、「購入」は在庫ステータスを販売可能に変更し、「販売」はアイテムを在庫から削除します（またはステータスを販売済みに変更します）。アイテムがインベントリに追加されると、そのステータスのみが変更されます（ウィジェット、バイオリンなど）。

于 2010-06-28T01:49:43.957 に答える
1

私はそれが非正規化されていないと主張します。繰り返しのグループは見当たりません。一意の主キーに依存するすべての属性。私には良いデザインのように聞こえます。

ここに質問がありますか？あなたはそれが受け入れられるという確認を探しているだけですか？

仮に、タイプごとに別々のテーブルに戻す必要があるという圧倒的なコンセンサスがあった場合、どうしますか？あなた自身の経験（より良いパフォーマンス、よりシンプルなプログラミング）からの証拠を無視し、Stackoverflow.comのアドバイスに従いますか？

于 2010-06-17T01:32:13.440 に答える