Ist das Design meiner EAV-basierten Produktvariantendatenbank solide, skalierbar und normalisiert, oder bietet das alternative relationale Design eine bessere Abfrage und Leistung?

Produktvarianten modellieren

Problem

Sie versuchen, Produktvarianten zu modellieren und glauben, dass EAV (Entity-Attribute-Value) erforderlich sein könnte. Hier ist Ihr Design:

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

Sie möchten wissen, ob Ihr Design solide ist, ob es Abfrage- und Skalierbarkeitsprobleme hat und ob es normalisiert ist.

Entwurfsüberlegungen

Ziel der Modellierung von Produktvarianten ist die Darstellung von Produkten, die unterschiedliche Variationen wie Größe, Farbe oder Material aufweisen können. Jede Variante ist normalerweise einer eindeutigen SKU (Stock Keeping Unit) zugeordnet.

Hier ist ein alternatives Design, das kein EAV verwendet:

+---------------+     +---------------+
| PRODUCTS      |-----< PRODUCT_SKUS  |
+---------------+     +---------------+
| #product_id   |     | #product_id   |
|  product_name |     | #sku_id       |
+---------------+     |  sku          |
        |             |  price        |
        |             +---------------+
        |                     |
+-------^-------+      +------^------+
| OPTIONS       |------< SKU_VALUES  |
+---------------+      +-------------+
| #product_id   |      | #product_id |
| #option_id    |      | #sku_id     |
|  option_name  |      | #option_id  |
+---------------+      |  value_id   |
        |              +------v------+
+-------^-------+             |
| OPTION_VALUES |-------------+
+---------------+
| #product_id   |
| #option_id    |
| #value_id     |
|  value_name   |
+---------------+

Primär Schlüssel (PKs), eindeutige Schlüssel (UKs) und Fremdschlüssel (FKs):

• PRODUKTE

  • PK: Produkt-ID
  • UK: Produktname

• OPTIONEN

  • PK: Produkt-ID, Options-ID
  • UK: Produkt-ID, Optionsname

• OPTION_VALUES

  • PK: Produkt-ID, Options-ID, Wert-ID
  • UK: Produkt-ID, Options-ID , value_name
  • FK: (product_id, option_id) verweist auf OPTIONS(product_id, option_id)

• PRODUCT_SKUS

  • PK: product_id, sku_id
  • UK: sku_id
  • FK: Produkt-ID verweist auf PRODUKTE (Produkt-ID) FK: (product_id, sku_id) Referenzen PRODUCT_SKUS(product_id, sku_id)
  FK: (product_id, option_id) verweist auf OPTIONS(product_id, option_id)
• FK: (product_id, option_id, value_id) verweist auf OPTION_VALUES(product_id, option_id, value_id)
  Datenbeispiel
  • Verwendung der folgenden Daten aus der bereitgestellten Tabelle:
  • Die Daten können in das eingegeben werden Tabellen wie folgt:

Das obige ist der detaillierte Inhalt vonIst das Design meiner EAV-basierten Produktvariantendatenbank solide, skalierbar und normalisiert, oder bietet das alternative relationale Design eine bessere Abfrage und Leistung?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!