ニーズに応じて mysql テーブルを設計する

みなさんこんにちは、まず最初に、この質問を閲覧していただきありがとうございます
要件について話させてください: モール プロジェクトの商品の属性。たとえば:
服には色とサイズの 2 つの属性があります。私のアイデアは記録することです。別の表にあります さまざまな属性の価格と在庫
例:
黒 - サイズ M - 70 元 - 35 個
黒 - サイズ L - 73 元 - 32 個
白 - サイズ L - 73 元 - 30 個
これテーブルはこのように設計されていますが、ここで問題が発生します。たとえば、携帯電話には、色、メモリ、通信事業者 (未契約、チャイナモバイル、チャイナユニコム、テレコム) などのいくつかの属性があります。
それでも次の方法に従う場合。上の服を見ると、余分な列があることが明らかです。それは
白 - 32G - 携帯電話契約 - 20 元 - 10 台
白 - 32G - チャイナユニコム契約電話 - 30 元 - 50 台
ゴールド - 32G -通信契約電話 - 10元 - 40台

これらの属性情報をすべてシリアル化して保存するのは良いのですが、Huawei 32G携帯契約の携帯電話を検索したいときに面倒なようです。何か良いアイデアがあれば提供していただきたいのですが、ありがとうございます。とても感謝しています
PS: ECSHOP のデザインを見たところ、商品には基本価格があり、その価格は基本価格に加算または減算されますが、私はこのアプローチにはあまり乗り気ではないようです。商品を追加するときに少し面倒

返信内容:

みなさんこんにちは、まず最初に、この質問を閲覧していただきありがとうございます
要件について話させてください: モール プロジェクトの商品の属性。たとえば:
服には色とサイズの 2 つの属性があります。私のアイデアは記録することです。別の表にあります さまざまな属性の価格と在庫
例:
黒 - サイズ M - 70 元 - 35 個
黒 - サイズ L - 73 元 - 32 個
白 - サイズ L - 73 元 - 30 個
これテーブルはこのように設計されていますが、ここで問題が発生します。たとえば、携帯電話には、色、メモリ、オペレータ (未契約、チャイナモバイル、チャイナユニコム、テレコム) などのいくつかの属性があります
それでも次の方法に従う場合上の服を見ると、もう 1 つの列が必要であることは明らかです。それは
白 - 32G - 携帯契約電話 - 20 元 - 10 台
白 - 32G - チャイナユニコム契約電話 - 30 元 - 50 台
ゴールド - 32G -通信契約電話 - 10元 - 40台

これらの属性情報がすべてシリアル化されて保存されていれば問題ありませんが、Huawei 32G 携帯契約の携帯電話を検索するときに面倒なようです。何か良いアイデアがあれば提供していただきたいのですが、ありがとうございます。とても感謝しています
PS: ECSHOP のデザインを見たところ、商品には基本価格があり、その価格は基本価格に加算または減算されますが、私はこのアプローチにはあまり乗り気ではないようです。商品を追加するときに少し面倒

現在の質問は他の人が尋ねたものであると言えます。あなたの質問について、私の回答をパラメータ化できます。
https://segmentfault.com/q/1010000005347571/a-1020000005347916
次のようにテーブルを設計できます。 :

商品一覧

製品ID	商品名
1	iPhone
2	キュウリ

製品属性テーブル

製品ID	仕様	カラー	価格
1	16g	ホワイト	4999
1	32g	ホワイト	5499
2	なし	なし	1

現在の練習プロジェクトには、このデザインが最適です
ただし、このデザインは、属性が多数ある場合、属性フィールドを追加する必要があり、一部の属性は商品で使用できない場合があります。この属性は無駄を引き起こし、属性テーブルが変更されずに展開されます。たとえば、製品 2 のキュウリは次のデザインに変更できます。 属性テーブル

属性ID属性名1仕様2カラー3価格商品カテゴリ一覧

IDを入力してください製品IDあ1b1c2製品属性テーブル

製品タイプID属性ID属性値あ116gあ2ホワイトあ34999b132gb2ホワイトb34999c4上海

デザインは上記の通りで、製品キュウリの属性は1つのデータのみを生成します。

個人的には、あなたの質問は 2 つの質問に分けられるべきだと思います。1 つ目は、製品テーブルの適切なデータ構造を設計する方法であり、2 つ目は、製品をより適切に検索する方法です。まず最初の質問は、商品リストの設計です。まず、モール ビジネスにどのような商品があるかを分析する必要があります。商品マスター テーブルと商品属性テーブルには 1 対多の関係があり、商品ごとに異なる関係構造を設計する必要がある場合があります。単純なアイデアは ecshop に似ています。ecshop も属性を別のテーブルにリストしますが、属性を 1 つのテーブルにリストするとデータの冗長性が生じます。
1. 属性テーブルでさらに多くのフィールドを設計できます。
1) 製品リストを設計します。アイテムを保存するための共通フィールド。
2). 属性テーブルのフィールドには仕様と色が含まれますが、一部のフィールドには冗長性があり、デフォルト値が配置される場合があります。
2. 商品をより効率的に検索する方法。
例えば、「Huawei 32G 携帯契約電話」と検索した場合、ユーザーが「Huawei 32G 携帯契約電話」と入力すると、商品を検索できます。 Huawei 32G 携帯契約電話が製品名ではない場合、システムは最初にそれをセグメント化し、次に検索して比較する必要があります。 Huawei 32Gモバイル契約機なら製品名そのままで直接検索できます。

属性テーブルを追加
product_id キー値
複数の属性のレコードをさらに数行追加するだけです