データベースの設計上の問題 - 循環参照

Question

を避けるためにしようと私は最高の私が所有している友人のために開発していますアプリのためにデータベース（MySQLの）をモデル化する方法を把握しようと、今日、ビットのためにこれをしていますパン屋。次のような仮定は以下のとおりです（外部）Bakers

• 多くは、多くのProducts
• BakersProductsが彼らの価格表を通じて製品の価格、またはパンファックスのために自分のパンを呼び出すいずれかの特定のスタッフによって隔週更新され、生産しますスタッフは、フロントエンドUIを介して更新します。
• マネージャは、が、となると予想される商品に基づいて注文を生成することができます。

だから、フロントエンドUIは、管理者は、純粋に彼女が順に希望の製品を選択し、順番に各製品の中から選択するパンのリストで彼女を提示できるようにすることができなければなりません。

つまり、Orders_has_Productsには、BakersProducts.bpIDへの参照が含まれている必要があります。私はこれを行う場合は、その後、私はProductsに（一種の）循環参照を作成するだろうと確信しているのに。

私はこれについて間違った方法を行ってきた、と本当に私が選択した製品の価格をacccommodateために私のデザインを再構築することができます方法についての誰のアドバイスをいただければ幸い確認イム - すなわち。 BakersProducts.bpIDを含めます。

ありがとうございました！これを解決する

Answer 1

私はミックスアップは、ビジネス・プロセスの観点からだと思う：あなたは受注と混ざっ依頼を取得しています。

請求書には、それぞれのサプライヤを指定せずに必要な製品のリストがありますが、注文は特定のサプライヤに向けられています（特定の価格参照コード（bpIDと思われます）。 1つの依頼で複数の仕入先に分割されている場合、複数の注文が発注されることがあります。単一の製品でも、仕入先の数量制限または配送地域のために、

ビューには、各請求ラインアイテムから生成されたオーダー明細を表示するリクエストがありますが、これはユーザーインターフェイスに関するものです。

Answer 2

一つの方法は、Productsテーブルを排除し、BakersProductsテーブルに商品名を移動するだけです。

これは本質的には、製パン機に固有の製品であれば、同じ製品を持ち歩くことを期待していない場合にのみ有効です。

ベーカーが同じ製品を運ぶことを期待している場合は、別のProductsテーブルを残しておきたいが、Order_has_Products.Products_productIDの代わりにOrder_has_Products.bpIDに変更する。場合/あなたが商品名（またはそのテーブルに入ってしまう可能性があり、メタデータを関連する他の製品）にアクセスする必要がある場合、あなただけのBakersProductsと製品間の結合を行うことができます。

Answer 3

これは循環参照ない、

• Order_has_products参照製品ので
• Order_has_products参照のBakersProducts
• BakersProducts参照製品

例えば、

、場合円形の参照は次のようになり

• Order_has_products参照それ以外の点から製品
• 製品参照BakersProducts
• BakersProducts参照Order_has_products

、循環参照、すなわち（データベース内に比較的正常です

1つの製品がOrder_has_productsテーブルで2回、つまり製品から直接1回参照されるため、デザインには単純な冗長性があります。テーブル、一度関連するBakersProductsレコードを介して。同期が外れる可能性はありますが、ビジネスルールは製品がベーカリーの前に選択されていると述べているので、それはまったく正しいことです。

他の方法であってもproductIDを含めることになります。なぜなら、クエリを高速化するには少しの非正規化が長くなる可能性があるからです。そうしないと、BakersProductsテーブルをスキャンする必要があります。 「水曜日にベーグルを食べましたか？」