0

これがシナリオです。

顧客に販売する e コマース Web サイトがあります。明らかにトランザクションがあります。たとえば、すべての販売について、販売に関する情報を記録します。それでは、「購入」テーブルを用意しましょう。どの列が必要ですか?

1) 「customer_id」を使用した「customer」テーブルへの外部キーのみが必要ですか? または 2) 「customer_name」、「customer_address」などのスナップショットを保持する...両方とも VARCHAR(x) または 3) 両方または 4) 「購入」テーブルを複数のテーブルに分割しますか? または、他の何か。

意見と理由を教えてください。乾杯

4

2 に答える 2

0

時間が問題領域に固有の概念である場合 (e コマースではそうです)、これもスキーマの第一級の設計概念として扱う必要があります。

私の好みのオプションは、時間の経過とともに変化する可能性のあるテーブルに「有効期間」インジケーターを設定することです。たとえば、顧客テーブルは次のようになります。

CUSTOMER
---------------
CustomerID   pk
RecordVersion pk
Name
EmailAddress
HomeAddressID fk
HomeAddressRecordVersion fk
ValidFrom
ValidUntil

次に、customerID 列と RecordVersion 列の両方を指定して、"purchases" テーブルを customers テーブルに結合します。そうすれば、注文時に顧客が使用していた電子メール アドレスを確認したい場合は、顧客テーブルからそのデータを取得できます。

顧客が使用した他の電子メール アドレスを知ることができます。これは、一部の購入データでそれを見つけることができるという理由だけでなく、それが顧客の記録の一部であるためです。

このモデルは非常に複雑になり、クエリが難しくなる可能性があるため、慎重に使用してください。しかし、特に製品、価格、割引、配送先住所などについては非常に便利です。eコマースソリューションで。

于 2012-04-20T12:09:08.350 に答える
0

Purchases テーブルに必要な列に関しては、要件に大きく依存します。通常、何らかの購入コード、購入日、購入顧客を最小限に抑え、さらに購入品のリスト (別の表) を用意します。

あなたが言及したオプションに関して、私はあなたがリレーショナル データベースを持っていて、NoSQL ソリューションに行かなかったと推測しています。

その場合、オプション (2) を破棄します。複数のレコードで顧客情報を複製する可能性があるため、リレーショナル スキーマにはうまく適合しません。同じ理由で、オプション (3) も破棄します。

オプション (1) は、リレーショナル データベース アプローチに適しています。購入があり、それぞれが独自の顧客にリンクされています。これにより、次のことを簡単に知ることができます。

  • 特定の顧客が行った購入。
  • どの顧客が具体的な購入を行ったか。
  • いくつかの基準によって与えられた顧客に基づいて購入検索を行います。
  • いくつかの基準によって与えられた購入に基づいて顧客検索を行います。
  • 等

特定の日付の顧客データを記録できるようにする必要がある場合は、常に顧客履歴テーブルを作成し、それを顧客テーブルにリンクすることを選択できます。購入日を指定すると、購入時にどの顧客データが「アクティブ」であったかを知ることができます。

(4)については、おっしゃっている意味がわからないのでお答えできません。

HTH

于 2012-04-20T11:56:41.933 に答える