2

飲食店の申し込みをしています。

一部の食品については、いくつかのアドオンを利用できます。たとえば、ピザのトッピングです。

オーダーテーブルの現在のデザイン-

|| 食品 ID || AddOnId

顧客が 1 つの食品に複数のアドオンを選択した場合 (ピザのトッピングとチーズ ディップなど)、どのように管理すればよいでしょうか?

私が考えた解決策 -

  1. AddOnId 列のコンマで区切られた ID (悪い考えだと思います)
  2. すべてのアドオンの組み合わせを別のアドオンとしてアドオン マスター テーブルに保存します。
  3. 注文した食品のアドオン専用の別のトランス テーブルを作成します。

提案してください。

PS - 同様の質問をたくさん検索しましたが、見つけられませんでした。

4

4 に答える 4

3

あなたの関係は次のように機能します。

(1 オーダー) には、(0 個以上のトッピング) を持つ (1 個以上の食品) があります。

このための最も詳細な構造は、3 つのテーブルになります (フード アイテムとトッピングに加えて):

  1. 注文
  2. 食品の注文
  3. 注文→食材→トッピング

さて、いくつかの追加の詳細について説明します。いくつかのフィールドを含むテーブルのフラッシュを開始しましょう...

  1. 注文
    1. オーダーID
    2. レジ
    3. サーバ
    4. 注文時間
  2. 食品の注文
    1. OrderToFoodItemId
    2. オーダーID
    3. FoodItemId
    4. サイズ
    5. ベースコスト
  3. 注文→食材→トッピング
    1. OrderToFoodItemId
    2. トッピングID
    3. 左右または全体

特定の注文以外には依存していない注文について、どれだけの情報を保存できるかに注目してください。

より多くのテーブルを維持するのは手間がかかるように見えるかもしれませんが、実際にはデータを構造化し、多くの追加の利点をもたらします... そのうちの少なくとも 1 つは、洗練されたレポートをより簡単に作成できることです。

于 2013-05-07T08:23:50.233 に答える
2

2 つの多対多の関係をその音でモデル化したいとします。

つまり、多くの製品 (食品) は多くの注文に属することができ、多くのアドオンは多くの製品に属することができます:

Orders
    Id

Products
    Id

OrderLines
    Id
    OrderId
    ProductId

Addons
    Id

ProductAddons
    Id
    ProductId
    AddonId

オプション 1 は、第 1 正規形を破っているため、確かに悪い考えです。

于 2013-05-07T08:17:35.903 に答える
1

そうです、最初の 1 つは、通常の形式のテーブルに準拠しておらず、維持するのが難しいため、悪い考えです (たとえば、アドオンを削除する場合は、文字列を解析して各行から ID を削除する必要があります -本当に遅い）。

既にテーブルを持っていても何も問題はありませんが、そのテーブルの主キーは (foodId, addonId) であり、foodId 自体ではありません。

または、別の「id」を追加して、複合主キーを使用しないようにすることもできます。

于 2013-05-07T08:17:28.920 に答える