0

ショッピング カート用のシンプルなデータベース モジュールを作成しました

私の質問は、ショッピング カートは M:N の関係で製品と出荷されますか? はいの場合、3 番目のテーブルを作成する必要があります。3 番目のテーブルを作成しましたが、意味がありません。T_SHOPPING_CART テーブルを作成し、複合主キーとして id 、product_id、quantity を使用して、製品の値を格納することができます。これらの詳細を格納する別のテーブルを作成するのではありません。3番目のテーブルまたは複合主キーにアプローチする方が良いのはどれですか。

ここに画像の説明を入力

4

1 に答える 1

-1

答えは基礎にあると思います。T_SHOPPING_CARTあなたはすでにそれを言っていT_PRODUCTて、m：nの関係があります。したがって、多対多の関係を分解すると、常に関連付けテーブル (または動名詞) が作成されます。

あなたのアプローチがうまくいかない理由を見てみましょう。T_SHOPPING_CART テーブルで複合 ID を使用したいだけです

T_SHOPPING_CART_ID(ID, Product_Id, quantity)

  1. 主キーに数量を含めると、ユーザーが数量を変更するたびに主キーが変更されます。それは良い設計方法ではありません。

  2. あなたが必要とするかもしれない他の属性はどうですか？毎回主キーとして追加しますか? 例えば。各ショッピング カートに関連付けられた割引を設計する必要があります。どのように保管しますか？テーブルと単純な m:1 の関係を構築できますDiscountか? 複合キーがあるため、非常に非効率的です。または、Discount を T_SHOPPING_CART テーブルの属性として保存すると、さらに深刻な欠陥、冗長性につながります。データの冗長性はあらゆる種類の異常を引き起こします。

T_SHOPPING_CART

ID   PRODUCT_ID    QUANTITY         DISCOUNT

1        101           33             2.3

1        102           20             2.3

ここでは、id=1 のショッピング カートの割引は 2.3 です。これは冗長です。つまり、更新、削除、異常の原因となる 2 つの場所に存在します。

  1. 製品を削除した場合、どのように対処しますか? カスケード デリートの場合、その商品が入っているショッピング カートがすべて失われます。カスケードしない場合、削除されたアイテムの代わりに何を保存しますか? Null、デフォルト値? 非常に悪いデザイン。

私の基本的な主張は、多対多の関係の基礎を読めば、すべての答えが見つかるということです。多対多は、常に 3 番目のテーブルにリンクする必要があります。

それが役に立てば幸い。

于 2014-09-15T14:02:46.767 に答える