2

正規化され、必要に応じて拡張できる強力なデータベースを構築しようとしています。これは私が問題を抱えているように見えますか？これはもっと効率的でしょうか？最も重要なことは、このデータベースは正規化されている可能性が最も高いかどうかです。ご覧いただきありがとうございます！

ここに画像の説明を入力してください

私を編集

多対多の関係を説明しようと思います。

属性：このサイトでは、銃、弾薬、付属品などを運ぶ計画があります。各製品には多くの属性があり、一部の製品には1つの属性があります。たとえば、リムファイア、ハンドガン、センターファイアの弾薬は同じ属性を持ちますが、ショットガンは異なる属性を持ちます。したがって、属性を柔軟にするためには、例のようにテーブルを設定する必要があると思いました。うまくいけば、それは理にかなっています-私はこれに苦労しました。

サプライヤー：製品には複数のサプライヤーが存在する可能性があります。

画像-製品にはメイン画像と不明な量の追加画像が含まれます。

カテゴリ：商品は複数のカテゴリに表示される可能性があります。たとえば、銃器は、戦術的な銃器だけでなく、半自動小銃にも登場する可能性があります。

レビュー：1つの商品に複数のレビューがあります。

productテーブルの「newfield」フィールドは無視してください。それは無人です、私はスクリーンショットの前にそれらを削除するのを忘れました。

編集II

みんなの提案を使ってスキーマを再設計しました。見て、私が近づいているかどうか見てください。皆さんの時間を本当に感謝しています;）

ここに画像の説明を入力してください

4

2 に答える 2

2

Productsテーブルに2つの「新しいフィールド」があるのはなぜですか？ジャンクションテーブルを介してリンクされているように見えるのに、Productsテーブルのreview_idとattribute_idがなぜですか？

1つの画像に実際に複数の商品が表示されていますか？そうでない場合は、product_imagesは必要ないか、必要ありません。product_idをimagesテーブルに配置するだけです。レビューと同じ質問。1つのレビューで複数の製品をカバーしていますか？そうでない場合は、ジャンクションテーブルを削除します。

製品には本当にサプライヤーとメーカーの両方がありますか？各メーカーが単一の製品しか供給していないというのは本当に本当ですか？

属性用に設定したKey-Valueメカニズムの背後にある考え方は何ですか？

自然キーを使用するのではなく、カテゴリや属性などのテーブルに追加のid列を決定した特別な理由はありますか？

于 2012-10-02T02:02:21.720 に答える
1

との間に多対多の関係が必要なのはなぜですか？属性は複数の製品にも属することができますか？そうでない場合は、テーブルを削除します。テーブルに呼び出される列を作成し、それを列のテーブルに参照します。productattributesproduct_attributesattribute_idproductattributesattribute_id

productまた、とimagesテーブルの関係は1対多に過ぎないと思います。テーブルを削除し、テーブルに。という名前imagesの新しい列を作成します。とでもこれを行います。product_imagesimage_pathproductreviews

スキーマに多対多の関係がたくさん見つかりました。

テーブルへの参加は、アプリケーションレベルでは非常にコストがかかることを常に忘れないでください。

于 2012-10-02T02:08:35.390 に答える