In dieser Veröffentlichung werde ich Magento 2- Datenstrukturen überprüfen, die ein Konzept wie EAV unterstützen . Entwickler müssen manchmal aus der Wildnis des Codes herauskommen und versuchen, ihre Lebensorte von der Höhe des Fluges eines Adlers aus zu überblicken - so können Sie sich auf Dinge konzentrieren, die wirklich wichtig oder nur groß sind. Also stieg ich aus.

Die Abkürzung EAV wird als Entität - Attribut - Wert angegeben (dies gilt für diejenigen, die dem obigen Link nicht gefolgt sind). Der Hauptvorteil von EAV ist die effiziente Nutzung des Datenbankbereichs in Fällen, in denen die mögliche Anzahl verschiedener Attribute (Eigenschaften, Parameter), die zur Beschreibung von Dingen (Entitäten) verwendet werden können, sehr groß ist, aber die Anzahl der Attribute, auf die tatsächlich Bezug genommen wird einzelnes Objekt ist relativ klein. Ein gutes Beispiel für einen solchen Fall im E-Commerce ist das Konzept des „Produkts“ - die wesentlichen Merkmale der Produkte „ TV “ (Bildschirmgröße) unterscheiden sich von den wesentlichen Merkmalen des Produkts „ Schlafsack “ (minimale angenehme Temperatur).
Was bietet Magento 2 zum Speichern von Daten im EAV-Format?
Namespace 'eav_'
In der eav_
Magento 2.3-Datenbank gibt es 21 Tabellen mit dem Präfix eav_
. Alle von ihnen können in drei Gruppen unterteilt werden:
eav_attribute
eav_entity
eav_form
Der einfachste Weg ist mit eav_form
- diese Tabellen beziehen sich auf die Anzeige einiger EAV-Daten auf der Benutzeroberfläche und nicht direkt auf die Platzierung von EAV-Daten in der Datenbank (ich betrachte nur Datenstrukturen und nur unter dem Gesichtspunkt der Informationsspeicherung, nicht deren Anzeige). Für das Experiment habe ich die eav_form
aus der Datenbank gelöscht, was mich nicht davon eav_form
hat, eine Bestellung im Geschäft eav_form
. Sie müssen also noch suchen, wo die Daten aus diesem Tabellenbereich verwendet werden und wie viel sie benötigen, damit Magento funktioniert.
Von den verbleibenden zwei bezieht sich die Gruppe eav_attribute
auf den Buchstaben A (ttribute) und die Gruppe eav_entity
auf den Buchstaben E (ntity) . Wo ist der Buchstabe V (alue) ?
Werte für Entitätsattribute müssen in den Tabellennamenssuffixen gesucht werden:
_datetime
_decimal
_int
_text
_ varchar
Sie können die Tabellen sehen, die beginnen mit:
catalog_category_entity_
catalog_product_entity_
customer_address_entity_
customer_entity_
eav_entity_
Eine einfache Multiplikation der Anzahl der Suffixe (5) mit der Anzahl der Präfixe (5) ergibt die Gesamtzahl der Tabellen (25), in denen die Speicherung von Wertedaten angenommen werden soll.
'eav_entity_type': Registrierung des Entitätstyps
Der Anfang von EAV in Magento muss in der Tabelle eav_entity_type
werden. Hier wird festgelegt, welche Arten von Entitätsattributwerten in der EAV-Struktur gespeichert werden. Daher bietet Magento 2.3 diese Option zunächst für die folgenden acht Entitäten an:
customer
customer_address
catalog_category
catalog_product
order
invoice
creditmemo
shipment
'eav_attribute': Attributregistrierung
Der nächste Schritt besteht darin, herauszufinden, welche Attribute diese Entitätstypen charakterisieren können. Diese Informationen befinden sich in der Tabelle eav_attribute
. Die Attributregistrierung wird im Register der Entitätstypen nach Fremdschlüssel geschlossen . In der Attributregistrierung zunächst 135 Einträge, die zu 4 Entitätstypen gehören:
Verwenden Sie die EAV-Struktur nicht zum Speichern von Daten. Das heißt, irgendwann war Begeisterung vorhanden und die Verwendung von EAV war für acht Arten von Unternehmen geplant, aber tatsächlich hörten sie bei 4 auf.
'eav_entity_': Geisterraum
Der Tabellenbereich eav_entity
ähnelt chinesischen Geisterstädten - von 9 eav_entity
enthalten nur zwei Daten:
eav_entity_type
: Dies ist ein Register der Entitätstypen, die ich oben erwähnt habe.eav_entity_attribute
: eav_entity_attribute
verwendet, um Attribute in Gruppen zu organisieren (näher an der Anzeige von Daten als an deren Speicherung). Diese Informationen beziehen sich direkter auf die Attribute selbst als auf die Entitäten (d. eav_attribute_
offensichtlich nicht aus dieser Gemeinde - sie hat einen Platz im Raum eav_attribute_
).
Die restlichen 7 Tabellen sind leer:
eav_entity
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text
eav_entity_varchar
Es ist sehr ähnlich zu dem Versuch, die Art und Weise des Speicherns von Werten für Entitätsattribute in einem Satz von Tabellen ( datetime
/ datetime
, decimal
, int
, text
, varchar
) zu varchar
anstatt 5 Tabellen mit den entsprechenden Suffixen für jeden Entitätstyp zu haben. Bei einem erfolglosen Versuch? Oder ist es die Zukunft von EAV in Magento?

Auf jeden Fall, Die Erde war formlos und leer, und die Dunkelheit war über dem Abgrund und dem Geist Gottes Diese Tabellen werden zunächst nicht verwendet.
Attributwerttypen
eav_entity_type
werden in der Tabelle eav_attribute
, eav_attribute
die Attribute selbst und ihre Bindung an die entsprechenden Entitätstypen werden in der Tabelle eav_attribute
. Und wie kann man bestimmen, wo nach dem Wert für ein solches Attribut einer solchen Entität gesucht werden soll?
Das Feld eav_attribute.backend_type
hilft uns dabei. Es zeigt, wo die Attributwerte gespeichert sind:
- statisch : In der Tabelle mit Daten über die Entität selbst (z. B. die Werte für das Attribut # 9 -
customer.email
müssen Sie in der Tabelle customer_entity in der email
Spalte suchen).
Für die übrigen Typen werden die Werte in separaten Tabellen gespeichert, in deren Namen das Präfix dem Entitätstyp ( customer_
, ...) und das Suffix einem der Datentypen entspricht:
datetime
decimal
int
text
varchar
Das heißt, die Werte für das Attribut # 79 catalog_product.special_from_date
Typ datetime
werden in der Tabelle catalog_product_entity_datetime
gespeichert. Die Werte für das Attribut # 77 catalog_product.price
befinden sich in der Tabelle catalog_product_entity_decimal
.
Was ist in der Tabelle eav_attribute
in Bezug auf eav_attribute
interessant zu sehen? Wie oben erwähnt, beschreibt diese Tabelle die Attribute für nur 4 der 8 in eav_entity_type
registrierten eav_entity_type
. Gleichzeitig sind für Entitäten wie customer
und customer_address
alle ursprünglich definierten Attribute vom static
Werttyp, dh sie sind normale Spalten in der Tabelle und nutzen den EAV-Ansatz nicht. Tabellen:
customer_entity_datetime
customer_entity_decimal
customer_entity_int
customer_entity_text
customer_entity_varchar
customer_address_entity_datetime
customer_address_entity_decimal
customer_address_entity_int
customer_address_entity_text
customer_address_entity_varchar
sind anfangs leer und können nur programmgesteuert verwendet werden (d. h. über das Admin-Panel kann ohne Erweiterungen von Drittanbietern nichts in diese Tabellen geschrieben werden).
EAV für Kategorien
Katalogkategorien - Dies ist die erste Entität, die mehr oder weniger den EAV-Ansatz in Magento verwendet. Der Entitätstyp ist catalog_category
, die Gesamtzahl der Anfangsattribute beträgt 30, von denen nicht statisch - 26. Das heißt, nur 4 Attribute ( children_count
, level
, path
, position
) werden in der Tabelle catalog_category_entity
gespeichert, der Rest wird in der catalog_category_entity_
[ datetime
| gespeichert decimal
| int
| text
| varchar
].
Die Struktur der Tabellen aus diesem Satz ist sowohl einander als auch ähnlichen Tabellen anderer Entitätstypen (Clients, deren Adressen usw.) sehr ähnlich:
CREATE TABLE `catalog_category_entity_datetime` ( `value_id` int(11) NOT NULL AUTO_INCREMENT, `attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0', `store_id` smallint(5) unsigned NOT NULL DEFAULT '0', `entity_id` int(10) unsigned NOT NULL DEFAULT '0', `value` datetime DEFAULT NULL, PRIMARY KEY (`value_id`), UNIQUE KEY `...` (`entity_id`,`attribute_id`,`store_id`), ... ) ...
Bei verschiedenen Arten von gespeicherten Werten ( datetime
/ datetime
, decimal
, int
, text
, varchar
) ändert sich nur der Typ der varchar
. Mit dieser Struktur können Sie einen separaten Wert ( value
) eines separaten Attributs ( attribute_id
) einer separaten Entität ( entity_id
) für eine separate Storefront ( store_id
) store_id
.
In Verbindung mit den Architekturmerkmalen von Magento wird eine zusätzliche Verbindung mit der Storefront store_id
- store_id
. Somit ist es möglich, die Werte desselben Attributs derselben Entität für verschiedene Schaufenster zu lokalisieren. Katalogkategorien sind die ersten Entitäten in Magento, für die Sie das EAV-Subsystem direkt nach dem Auspacken verwenden können. Sie können Werte für Verzeichnisattribute über das Admin-Panel festlegen.

Sie können nicht nur unterschiedliche Werte für Textattribute angeben, die in die Sprache der entsprechenden Storefront übersetzt werden, sondern auch Attribute anderer Typen lokalisieren. In Erwartung der Weihnachtsferien in ru storefront für das Attribut catalog_category.custom_design_from
Sie die Werte beispielsweise am 7. Januar des nächsten Jahres und in en storefront am 24. Dezember festlegen.

EAV für Produkte
Im Allgemeinen ist dies derselbe Unternehmenstyp, für den EAV in Magento gestartet wurde. Der Entitätstyp ist catalog_product
mit den gesamten Anfangsattributen - 63, davon nicht statisch - 56. Die Struktur der Tabellen, die EAV für Produkte unterstützen, ähnelt der Struktur der Tabellen für Kataloge. Es gibt jedoch einen signifikanten Unterschied. Für Produkte können Sie über das Admin-Panel neue Attribute erstellen. Dies ist die standardmäßige Magento-Funktionalität. Wenn Magento nur EAV-Datenstrukturen für andere Entitäten basierend auf deren Softwarefüllung bereitstellt, wird für Produkte eine Schnittstelle implementiert, die es Ihnen ermöglicht, dies auf Benutzerebene (Geschäftsleiter) zu tun - Geschäfte / Attribute / Produkt .
Für die Produkte gibt es zwei weitere Tabellen, die sich auf EAV beziehen:
eav_attribute_set
eav_attribute_group
Im Großen und Ganzen zeigen sie Informationen eher an als speichern sie. Produktattribute werden zu einem set
und beim Erstellen eines Produkts wird ihm ein Satz von Attributen zugewiesen, mit denen eine Produktkarte beispielsweise für ein Fernsehgerät ausgefüllt und eine Reihe von Attributen ausgewählt werden kann, die sich speziell auf Haushaltsgeräte beziehen (oder sogar für eine Gruppe von Produkten, die als "Fernsehgeräte" bezeichnet werden). Das Zusammenführen von Attributen zu Sets erfolgt in den Stores / Attributes / Product / Attribute Set :

Insgesamt
Meiner Meinung nach ist Magento ein gutes Beispiel dafür, dass die Angemessenheit der Verwendung von EAV recht eng ist. Wenn Sie die Verwendung von EAV für 8 Entitäten ( eav_entity_type
) mit einem Lesezeichen eav_entity_type
, wird die EAV-Notation nur für 4 Entitäten ( eav_attribute
) verwendet, von denen nur 2 Entitäten catalog_category
EAV-Attribute haben - catalog_category
und catalog_product
. Darüber catalog_category
EAV-Attribute für catalog_category
nicht für den beabsichtigten Zweck verwendet (eine große Anzahl verschiedener Attribute zur Beschreibung einer Entität mit einer kleinen Anzahl von Attributen, die sich auf eine einzelne Instanz beziehen ), sondern für die "Showcase-Lokalisierung" von Attributwerten ( dieselbe Menge von Attributen für eine Entität) "Katalogkategorie" mit der Fähigkeit eines Instanzattributs, unterschiedliche Bedeutungen für unterschiedliche Schaufenster zu haben ).
Die vollständige Verwendung von EAV wird nur für catalog_product
(obwohl es auch eine Beimischung von "Storefront-Lokalisierung" gibt, dies ist jedoch eine Erweiterung des EAV-Modells und nicht dessen Entweihung, wie dies bei Kategorien der Fall ist). Aber mit Produkten enthüllt Magento EAV vollständig - Magento-Anwendung kann sicher verwendet werden, um die Prinzipien von EAV klar zu demonstrieren.