正規化されたデータベース設計は、エンティティ属性値 (EAV) モデルの代替として製品バリアントを効果的にモデル化するにはどうすればよいでしょうか?

製品バリアントのモデリング

あなたは製品バリアントをモデル化しようとしていますが、EAV (Entity-Attribute-Value) の使用について懸念がありました。検討できる代替設計を次に示します。

正規化設計

次の設計は、製品バリアントのデータ構造を正規化します:

+---------------+     +-----------------+
| PRODUCTS      |-----< PRODUCT_VARIANTS  |
+---------------+     +-----------------+
| #product_id   |     | #product_id       |
|  product_name |     | #variant_id       |
+---------------+     |  sku_id           |
         |             +-----------------+
         |                       |
+--------^--------+     +--------^--------+
| PRODUCT_OPTIONS |-----< VARIANT_VALUES  |
+-----------------+     +-----------------+
| #product_id     |     | #product_id     |
| #option_id      |     | #variant_id     |
+--------v--------+     | #option_id      |
         |              |  value_id       |
+-----------------+     +--------v--------+
| OPTIONS         |              |
+-----------------+              |
| #option_id      |              |
|  option_name    |              |
+-----------------+              |
         |                       |
 +-------^-------+               |
 | OPTION_VALUES |---------------+
 +---------------+
 | #option_id    |
 | #value_id     |
 |  value_name   |
 +---------------+

プライマリ、ユニーク、および外部キー:

PRODUCTS
- PK: product_id
- UK: product_name

OPTIONS
- PK: option_id
- UK: option_name

OPTION_VALUES
- PK: option_id, value_id
- UK: option_id, value_name
- FK: option_id REFERENCES OPTIONS (option_id)

PRODUCT_OPTIONS
- PK: product_id, option_id
- FK: product_id REFERENCES PRODUCTS (product_id)
- FK: option_id REFERENCES OPTIONS (option_id)

PRODUCT_VARIANTS
- PK: product_id, variant_id
- UK: sku_id
- FK: product_id REFERENCES PRODUCTS (product_id)

VARIANT_VALUES
- PK: product_id, variant_id, option_id
- FK: product_id, variant_id REFERENCES PRODUCT_VARIANTS (product_id, variant_id)
- FK: product_id, option_id REFERENCES PRODUCT_OPTIONS (product_id, option_id)
- FK: option_id, value_id REFERENCES OPTION_VALUES (option_id, value_Id)

仕組み

• 製品には、名前などの基本的な製品情報が含まれています。
• OPTIONS には、次のような使用可能なオプションがリストされます。サイズまたは色。
• OPTION_VALUES は、Small や Red などのオプションの特定の値を保持します。
• PRODUCT_OPTIONS は、どのオプションが製品に関連付けられているかをマップします。 .
• PRODUCT_VARIANTS実際の製品バリアントとその SKU が保存されます。
• VARIANT_VALUES は、バリアントをオプションの値にリンクします。

この設計により、オプションとその値を定義できます独立しているため、将来的に新しいオプションや値を柔軟に追加できるようになります。

サンプルデータ

質問のスプレッドシートに基づいてこれらのテーブルにデータを入力する方法の例を次に示します。

PRODUCTS
========
product_id product_name
---------- ------------
1          Widget 1
2          Widget 2
3          Widget 3

OPTIONS
=======
option_id option_name
--------- -----------
1         Size SL
2         Color
3         Size SM
4         Class
5         Size ML

OPTION_VALUES
=============
option_id value_id value_name
--------- -------- ------------
1         1        Small        (Size SL)
1         2        Large        (Size SL)
2         1        White        (Color)
2         2        Black        (Color)
3         1        Small        (Size SM)
3         2        Medium       (Size SM)
4         1        Amateur      (Class)
4         2        Professional (Class)
5         1        Medium       (Size ML)
5         2        Large        (Size ML)

PRODUCT_OPTIONS
===============
product_id option_id
---------- ---------
1          1         (Widget 1; Size SL)
1          2         (Widget 1; Color)
2          3         (Widget 2; Size SM)
3          4         (Widget 3; Class)
3          5         (Widget 4; Size ML)

PRODUCT_VARIANTS
================
product_id variant_id sku_id
---------- ---------- ------
1          1          W1SSCW (Widget 1)
1          2          W1SSCB (Widget 1)
1          3          W1SLCW (Widget 1)
1          4          W1SLCB (Widget 1)
2          1          W2SS   (Widget 2)
2          2          W2SM   (Widget 2)
3          1          W3CASM (Widget 3)
3          2          W3CASL (Widget 3)
3          3          W3CPSM (Widget 3)
3          4          W3CPSL (Widget 3)

VARIANT_VALUES
==============
product_id variant_id option_id value_id
---------- ---------- --------- --------
1          1          1         1        (W1SSCW; Size SL; Small)
1          1          2         1        (W1SSCW; Color; White)
1          2          1         1        (W1SSCB; Size SL; Small)
1          2          2         2        (W1SSCB; Color; Black)
1          3          1         2        (W1SLCW; Size SL; Large)
1          3          2         1        (W1SLCW; Color; White)
1          4          1         2        (W1SLCB; Size SL; Large)
1          4          2         2        (W1SLCB; Color; Black)
2          1          3         1        (W2SS; Size SM; Small)
2          2          3         2        (W2SM; Size SM; Medium)
3          1          4         1        (W3CASM; Class; Amateur)
3          1          5         1        (W3CASM; Size ML; Medium)
3          2          4         1        (W3CASL; Class; Amateur)
3          2          5         2        (W3CASL; Size ML; Large)
3          3          4         2        (W3CPSM; Class; Professional)
3          3          5         1        (W3CPSM; Size ML; Medium)
3          4          4         2        (W3CPSL; Class; Professional)
3          4          5         2        (W3CPSL; Size ML; Large)

利点

• より優れた柔軟性とスケーラビリティ。
• 複雑な結合を回避することでクエリを簡素化します。
• 外部キーを通じてデータの整合性を強化します。

欠点

• 以前と比べてより多くのテーブルが必要ですEAV。
• より複雑なデータベースの設計とメンテナンスが必要になる場合があります。

結論

この正規化された設計は、モデリング用の EAV の実行可能な代替手段です。製品のバリエーション。柔軟性、スケーラビリティ、データの整合性を提供すると同時に、クエリも比較的簡単です。ただし、EAV と正規化のどちらを選択するかは、アプリケーションの特定の要件とトレードオフに基づいて選択する必要があります。

以上が正規化されたデータベース設計は、エンティティ属性値 (EAV) モデルの代替として製品バリアントを効果的にモデル化するにはどうすればよいでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。