Wie kann ein normalisiertes Datenbankdesign Produktvarianten als Alternative zum Entity-Attribute-Value (EAV)-Modell effektiv modellieren?

Produktvarianten modellieren

Sie versuchen, Produktvarianten zu modellieren und hatten Bedenken hinsichtlich der Verwendung von EAV (Entity-Attribute-Value). Hier ist ein alternatives Design, das Sie in Betracht ziehen könnten:

Normalisiertes Design

Das folgende Design normalisiert die Datenstruktur für Produktvarianten:

+---------------+     +-----------------+
| 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   |
 +---------------+

Primäre, eindeutige und Fremdschlüssel:

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)

Wie it Works

• PRODUCTS enthält grundlegende Produktinformationen wie den Namen.
• OPTIONEN listet die verfügbaren Optionen auf, z. B. Größe oder Farbe.
• OPTION_VALUES enthält die spezifischen Werte von Optionen, wie z. B. Klein oder Rot.
• PRODUCT_OPTIONS bildet ab, welche Optionen mit Produkten verknüpft sind.
• PRODUCT_VARIANTS speichert die tatsächlichen Produktvarianten zusammen mit ihren SKUs.
• VARIANT_VALUES verknüpft Varianten mit ihrer Option Werte.

Dieses Design ermöglicht es Ihnen, die Optionen und ihre Werte unabhängig zu definieren, sodass Sie in Zukunft flexibel neue Optionen oder Werte hinzufügen können.

Beispieldaten

Hier ist ein Beispiel dafür, wie Sie Daten in diese Tabellen eingeben können, basierend auf der Tabelle in Ihrem Frage:

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)

Vorteile

• Bietet mehr Flexibilität und Skalierbarkeit.
• Vereinfacht die Abfrage durch Vermeidung komplexer Verknüpfungen.
• Erzwingt die Datenintegrität durch Fremdzugriff Schlüssel.

Nachteile

• Erfordert mehr Tabellen im Vergleich zu EAV.
• Kann ein komplexeres Datenbankdesign erfordern und Wartung.

Fazit

Dieses normalisierte Design ist eine praktikable Alternative zu EAV für die Modellierung von Produktvarianten. Es bietet Flexibilität, Skalierbarkeit und Datenintegrität und ist gleichzeitig relativ einfach abzufragen. Die konkrete Wahl zwischen EAV und Normalisierung sollte jedoch auf der Grundlage der spezifischen Anforderungen und Kompromisse Ihrer Anwendung getroffen werden.

Das obige ist der detaillierte Inhalt vonWie kann ein normalisiertes Datenbankdesign Produktvarianten als Alternative zum Entity-Attribute-Value (EAV)-Modell effektiv modellieren?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!