25

タイトルが少しでも参考になれば幸いです。MySQL をデータベースとして使用しています

製品のデータベースを構築していますが、製品のバリエーションの保管価格/SKU を処理する方法がわかりません。製品には無制限のバリエーションがあり、各バリエーションの組み合わせには独自の価格/SKU/その他があります。

これは、現時点で製品/バリエーションテーブルをセットアップする方法です。

PRODUCTS
+--------------------------+
| id | name | description  |
+----+------+--------------+
| 1  | rug  | a cool rug   |
| 2  | cup  | a coffee cup |
+----+------+--------------+

PRODUCT_VARIANTS
+----+------------+----------+-----------+
| id | product_id | variant  | value     |
+----+------------+----------+-----------+
| 1  | 1          | color    | red       |
| 2  | 1          | color    | blue      |
| 3  | 1          | color    | green     |
| 4  | 1          | material | wool      |
| 5  | 1          | material | polyester |
| 6  | 2          | size     | small     |
| 7  | 2          | size     | medium    |
| 8  | 2          | size     | large     |
+----+------------+----------+-----------+

(`products.id` is a foreign key of `product_variants.product_id`)

このサンプル データで SQLFiddle を作成しました: http://sqlfiddle.com/#!2/2264d/1

ユーザーは任意のバリエーション名を入力でき ( product_variants.variant)、それに任意の値を割り当てることができます ( product_variants.value)。ユーザーが入力できるバリエーション/値の量に制限があってはなりません。

これが私の問題が発生する場所です: 誰かが以前に存在しなかったバリアントを持つ製品を追加するたびに、新しいテーブル/列を追加せずに各バリエーションの価格/SKU を保存します。

各バリエーションの価格は同じかもしれませんが、SKU は各製品に固有です。たとえば、製品1には 6 つの異なる組み合わせ (3 色 * 2 素材) があり、製品2には 3 つの異なる組み合わせ (3 サイズ * 1) しかありません。

組み合わせをテキストとして保存することを考えました。

+------------+-----------------+-------+------+
| product_id | combination     | price | SKU  |
+------------+-----------------+-------+------+
| 1          | red-wool        | 50.00 | A121 |
| 1          | red-polyester   | 50.00 | A122 |
| 1          | blue-wool       | 50.00 | A123 |
| 1          | blue-polyester  | 50.00 | A124 |
| 1          | green-wool      | 50.00 | A125 |
| 1          | green-polyester | 50.00 | A125 |
| 2          | small           | 4.00  | CD12 |
| 2          | medium          | 4.00  | CD13 |
| 2          | large           | 3.50  | CD14 |
+------------+-----------------+-------+------+

しかし、このデータを表現するための、より優れた正規化された方法が必要です。仮定の状況: $10 未満の青色の製品を検索できるようにしたいと考えています。上記のデータベース構造では、テキストを解析せずに行うことはできません。これは避けたいことです。

どんな助け/提案も大歓迎です=）

4

7 に答える 7

46

問題に正規化を適用すると、解決策は与えられたとおりです。SQL Fiddleで実行して確認します。

CREATE TABLE products (
    product_id  int AUTO_INCREMENT PRIMARY KEY,
    name        varchar(20),
    description varchar(30)
);

INSERT INTO products
    (name, description)
VALUES
    ('Rug', 'A cool rug' ),
    ('Cup', 'A coffee cup');

-- ========================================

CREATE TABLE variants (
    variant_id int AUTO_INCREMENT PRIMARY KEY,
    variant    varchar(50)
);

INSERT INTO variants
    (variant)
VALUES
    ('color'),
    ('material'),
    ('size');

-- ========================================

CREATE TABLE variant_value (
    value_id   int AUTO_INCREMENT PRIMARY KEY,
    variant_id int,
    value      varchar(50)
);

INSERT INTO variant_value
    (variant_id, value)
VALUES
    (1, 'red'),
    (1, 'blue'),
    (1, 'green'),
    (2, 'wool'),
    (2, 'polyester'),
    (3, 'small'),
    (3, 'medium'),
    (3, 'large');

-- ========================================

CREATE TABLE product_variants (
    product_variants_id int AUTO_INCREMENT PRIMARY KEY,
    product_id          int,
    productvariantname  varchar(50),
    sku                 varchar(50),
    price               float
);

INSERT INTO product_variants
    (product_id, productvariantname, sku, price)
VALUES
    (1, 'red-wool', 'a121', 50),
    (1, 'red-polyester', 'a122', 50);

-- ========================================

CREATE TABLE product_details (
    product_detail_id   int AUTO_INCREMENT PRIMARY KEY,
    product_variants_id int,
    value_id            int
);

INSERT INTO product_details
    (product_variants_id, value_id)
VALUES
    (1, 1),
    (1, 4),
    (2, 1),
    (2, 5);
于 2013-10-05T17:01:17.830 に答える
7

私は4つのテーブルを使用します：

generic_product: product_id, name, description

例: 1, '敷物', 'コーヒー敷物' / 2, 'マグ', 'コーヒー マグ'

generic_product_property: product_id, property_id, property_name

例: 1, 10, '色' / 1, 11, '素材'

sellable_product: sku, product_id, price

例: 'A121', 1, 50.00 / 'A122', 1, 45.00

sellable_product_property: sku, property_id, property_value

例: 'A121', 10, 'レッド' / 'A121', 11, 'ウール' / 'A122', 10, 'グリーン' / 'A122', 11, 'ウール'

これにより、ユーザーは希望する販売可能な製品のプロパティを定義できます。

アプリケーションは、そのビジネス ロジックを使用して、sellable_products が完全に記述されていることを確認する必要があります (該当するすべての一般的な製品プロパティについて、販売可能な製品プロパティが定義されていることを確認してください)。

于 2013-10-05T07:52:25.643 に答える
1

これは、私がSOで彼女をしばらく前に見た別の質問に似ています

データベースの設計 : どちらがより良いアプローチですか?

そこを見ると、基本的に同じ狭い (属性ベース) 対 広いテーブルの質問をしていることがわかります。シナリオに応じて両方を使用しましたが、現在の実装方法には本当に注意してください。そして、それらのバリアントを SKU に一致させる良い方法が実際には存在しないという事実 (少なくとも私が考えることができる方法ではない) により、テーブルを変更せざるを得なくなる可能性があります。

非常に多くの異なるバリアントがある場合は、キー値データベースやその他の NoSQL ソリューションも検討する必要があります。

于 2013-10-02T21:33:49.437 に答える
1

Sku は主キーです。sku を使用してバリアント テーブルへの外部キー リレーションシップを設定できます。productid は完全に忘れてください。

テーブル x (sku、価格、説明) の主キー sku を作成します。

于 2013-10-11T13:46:57.293 に答える