Magento 2 EAV: Überblick über Datenstrukturen

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.


Bild


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:


  • customer
  • customer_address
  • catalog_category
  • catalog_product


    Worüber spricht das? Nun, zumindest diese anderen Arten von Entitäten:


  • order
  • invoice
  • creditmemo
  • shipment

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?


Bild


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.


Bild


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.


Bild


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 :


Bild


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.

Source: https://habr.com/ru/post/de441122/


All Articles