web-dev-qa-db-ja.com

eコマースストア向けの実用的なmysqlスキーマアドバイス-製品と属性

私は現在、最初のeコマースアプリケーション(mySQL&Laravel Framework))を計画しています。

私はさまざまな製品を持っていますが、それらはすべて異なる属性を持っています。製品を非常に簡単に説明します。メーカーがある場合もあれば、ない場合もあります。直径がある場合もあれば、幅、高さ、奥行きがある場合、ボリュームがある場合もあります。

オプション1:マスター製品テーブルを作成し、特定の製品タイプ(ポリモーフィックリレーションシップ)ごとに個別のテーブルを作成します。そうすれば、productsテーブルに不要なnullフィールドがなくなります。

オプション2:多くのnull行があるという事実にもかかわらず、すべての可能なフィールドを使用して、productsテーブルを作成します。

オプション3:各属性タイプが独自のテーブルを持つように正規化します。

オプション4:attributesテーブルと、実際のデータ型に関係なく、値がvarcharであるattribute_valuesテーブルを作成します。製品テーブルには、属性テーブルとの多:多の関係があります。

オプション5:製品テーブルに配置されたすべてまたはほとんどの製品に共通の属性、およびカテゴリテーブルに添付された製品の特定のカテゴリに固有の属性。

私の考えでは、これらの属性と並べ替えによる簡単な製品フィルタリングを可能にしたいと考えています。また、フロントエンドを高速にして、製品レコードの挿入と更新のパフォーマンスへの懸念を減らしたいと思います。

膨大な実装オプションに少し圧倒され、最善のアプローチ方法に関して適切な答えを見つけることができません。誰かが私を正しい方向に向けることができますか?

理想的な世界では、次のような機能を http://www.glassesdirect.co.uk/products/ をeコマースストアに提供したいと考えています。ご覧のように、サイドバーで、メガネをフィルタリングする属性を選択できます。例えば男性/女性またはプラスチック/金属/チタンなど...

または、mySqlリレーショナルデータベースのアイデアをダンプして、mongodbを学習する必要がありますか?

3
Gravy

ここで重要なのは柔軟性です。それぞれ異なる属性のセットを持つさまざまなタイプの製品があるため、属性タイプだけでなく製品も変更されると想定するのは公正です。そのため、商品テーブルに属性を含めるのはあまり便利ではありません。

これがあなたができることです:

  1. 製品タイプの表があります
  2. 製品タイプのテーブルと多対1の関係にある製品のテーブルがある
  3. 属性タイプのテーブルがあります
  4. 製品タイプと属性タイプの間の(多対多)関係のテーブルを持っている
  5. 属性タイプ、属性値、製品の主キーを含むテーブルがあります

この設計により、大きな柔軟性が得られます。テーブルは正規化され、冗長性はなく、製品の定義が変更された場合にテーブルスキームを変更する必要はありません。データベースが適切にインデックス化され、トールステンミュラーが示唆するように他の検索最適化手法が暗示される場合、このソリューションは機能します。

5
superM