Dans cette publication, je passerai en revue les structures de données de Magento 2 qui prennent en charge un concept tel que l' EAV . Les développeurs ont parfois besoin de sortir du monde sauvage du code et d'essayer de sonder leurs lieux de vie depuis la hauteur du vol d'un aigle - cela vous permet de vous concentrer sur des choses qui sont vraiment importantes ou simplement importantes. Alors je suis sorti.
L'acronyme EAV est divulgué comme Entité - Attribut - Valeur (c'est pour ceux qui n'ont pas suivi le lien ci-dessus). Le principal « plus » de l'EAV est l'utilisation efficace de l'espace de base de données dans les cas où le nombre possible d'attributs différents (propriétés, paramètres) qui peuvent être utilisés pour décrire des choses (entités) est très large, mais le nombre d'attributs, qui se réfère en fait à l'objet individuel est relativement petit. Un bon exemple d'un tel cas dans le commerce électronique est le concept de «produit» - les attributs significatifs des produits « TV » (taille d'écran) diffèrent des attributs significatifs des produits « sac de couchage » (température minimale de confort).
Alors, que propose Magento 2 pour stocker des données au format EAV?
espace de noms 'eav_'
Dans la base de données Magento 2.3 eav_ , il y a 21 tables avec le préfixe eav_ . Tous peuvent être divisés en trois groupes:
eav_attributeeav_entityeav_form
La méthode la plus simple consiste à eav_form - ces tableaux concernent l'affichage de certaines données EAV sur l'interface utilisateur et ne concernent pas directement le placement des données EAV dans la base de données (je ne considère que les structures de données et uniquement du point de vue du stockage des informations, pas de leur affichage). Pour l'expérience, j'ai supprimé les eav_form espace eav_form de la base de données et cela ne m'a pas empêché de passer une commande dans le magasin. Vous devez donc toujours chercher où les données de cet espace table sont utilisées et combien il faut pour que Magento fonctionne.
Des deux autres, le groupe eav_attribute fait référence à la lettre A (ttribute) et le groupe eav_entity à la lettre E (ntity) . Où est la lettre V (alue) ?
Les valeurs des attributs d'entité doivent être recherchées dans les suffixes de nom de table:
_datetime_decimal_int_text_ varchar
Vous pouvez voir que les tableaux commençant par:
catalog_category_entity_catalog_product_entity_customer_address_entity_customer_entity_eav_entity_
Une simple multiplication du nombre de suffixes (5) par le nombre de préfixes (5) nous donne le nombre total de tables (25) dans lesquelles le stockage de valeurs- données est supposé.
'eav_entity_type': registre de type d'entité
Le début de l'EAV dans Magento doit être trouvé dans la table eav_entity_type . C'est ici qui définit quels types de valeurs d'attribut d'entités seront stockées dans la structure EAV. Donc, initialement, Magento 2.3 propose cette option pour les huit entités suivantes:
customercustomer_addresscatalog_categorycatalog_productorderinvoicecreditmemoshipment
'eav_attribute': registre d'attributs
L'étape suivante consiste à découvrir quels attributs ces types d'entités peuvent caractériser. Ces informations se eav_attribute dans la table eav_attribute . Le registre d'attributs a une fermeture sur le registre des types d'entité par clé étrangère . Dans le registre d'attributs, initialement 135 entrées appartenant à 4 types d'entités:
N'utilisez pas la structure EAV pour stocker des données. C'est-à-dire qu'à un certain stade, l'enthousiasme était présent et l'utilisation de l'EAV était prévue pour huit types d'entités, mais en fait, elles se sont arrêtées à 4.
'eav_entity_': espace fantôme
L' eav_entity table eav_entity ressemble aux villes fantômes chinoises - sur 9 tables spatiales, seules deux contiennent des données:
eav_entity_type : c'est un registre des types d'entités que j'ai mentionné ci-dessus;eav_entity_attribute : utilisé pour organiser les attributs en groupes (plus proche de l'affichage des données que de leur stockage); cette information se rapporte plus directement aux attributs eux-mêmes qu'aux entités (c'est-à-dire, évidemment pas de cette paroisse - elle a une place dans l'espace eav_attribute_ );
Les 7 tables restantes sont vides:
eav_entityeav_entity_datetimeeav_entity_decimaleav_entity_inteav_entity_storeeav_entity_texteav_entity_varchar
C'est très similaire à essayer d'unifier la façon de stocker les valeurs des attributs d'entité dans un ensemble de tables ( datetime , decimal , int , text , varchar ) au lieu d'avoir 5 tables avec les suffixes correspondants pour chaque type d'entité. Sur une tentative infructueuse? Ou est-ce l'avenir de l'EAV à Magento?
Bref La terre était informe et vide, et les ténèbres étaient au-dessus de l'abîme, et l'Esprit de Dieu ces tableaux ne sont pas initialement utilisés.
Types de valeur d'attribut
eav_entity_type types d' eav_entity_type sont définis dans la table eav_attribute , eav_attribute les attributs eux-mêmes et leur liaison aux types d'entité correspondants sont définis dans la table eav_attribute . Et comment déterminer où chercher la valeur d'un tel attribut d'une telle entité?
Le champ eav_attribute.backend_type nous y aidera. Il montre où les valeurs d'attribut sont stockées:
- statique : dans le tableau avec des données sur l'entité elle-même (par exemple, les valeurs de l'attribut # 9 -
customer.email , vous devez rechercher dans le tableau customer_entity dans la colonne email );
Pour les types restants, les valeurs sont stockées dans des tableaux séparés, aux noms desquels le préfixe correspond au type d'entité ( customer_ , ...) et le suffixe à l'un des types de données:
datetimedecimalinttextvarchar
Autrement dit, les valeurs de l'attribut # 79 catalog_product.special_from_date type datetime sont stockées dans la table catalog_product_entity_datetime . Les valeurs de l'attribut # 77 catalog_product.price trouvent dans la table catalog_product_entity_decimal .
Qu'est-ce qui est intéressant à voir dans la table eav_attribute par rapport aux types de valeurs? Comme je l'ai noté ci-dessus, ce tableau décrit les attributs pour seulement 4 des 8 types d'entités enregistrés dans eav_entity_type . Dans le même temps, pour des entités telles que customer et customer_address tous les attributs qui ont été initialement définis sont de type valeur static - c'est-à-dire que ce sont des colonnes ordinaires dans la table et ne tirent pas parti de l'approche EAV. Tableaux:
customer_entity_datetimecustomer_entity_decimalcustomer_entity_intcustomer_entity_textcustomer_entity_varcharcustomer_address_entity_datetimecustomer_address_entity_decimalcustomer_address_entity_intcustomer_address_entity_textcustomer_address_entity_varchar
sont initialement vides et ne peuvent être utilisés que par programme (c'est-à-dire que via le panneau d'administration, sans extensions tierces, il n'y a aucun moyen d'écrire quoi que ce soit dans ces tables).
EAV pour les catégories
Catégories de catalogue - c'est la première entité qui utilise plus ou moins l'approche EAV dans Magento. Le type d'entité est catalog_category , le total des attributs initiaux est 30, dont non statique - 26. Autrement dit, seuls 4 attributs ( children_count , level , path , position ) sont stockés dans la table catalog_category_entity , les autres sont stockés dans catalog_category_entity_ [ datetime | decimal | int | text | varchar ].
La structure des tables de cet ensemble est très similaire les unes aux autres et à des tables similaires d'autres types d'entités (clients, leurs adresses, etc.):
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`), ... ) ...
Pour différents types de valeurs stockées ( datetime , decimal , int , text , varchar ), seul le type de la colonne de value change. Cette structure vous permet d'enregistrer une valeur distincte ( value ) d'un attribut distinct ( attribute_id ) d'une entité distincte ( entity_id ) pour une vitrine distincte ( store_id ).
En relation avec les fonctionnalités architecturales de Magento, une connexion supplémentaire avec la vitrine est store_id - store_id . Ainsi, il est possible de localiser les valeurs du même attribut de la même entité pour différentes vitrines. Les catégories de catalogue sont les premières entités de Magento pour lesquelles vous pouvez utiliser le sous-système EAV directement hors de la boîte. Vous pouvez définir des valeurs pour les attributs de répertoire via le panneau d'administration.
Vous pouvez non seulement donner des valeurs différentes pour les attributs de texte, en les traduisant dans la langue de la vitrine correspondante, mais également localiser les attributs d'autres types. Par exemple, en prévision des vacances de Noël sur la vitrine ru pour l'attribut catalog_category.custom_design_from vous pouvez définir les valeurs le 7 janvier de l'année prochaine et sur la devanture le 24 décembre.
EAV pour les produits
En général, il s'agit du même type d'entité pour lequel EAV a été lancé à Magento. Le type d'entité est catalog_product , du total des attributs initiaux - 63, dont non statique - 56. La structure des tables prenant en charge EAV pour les produits est similaire à la structure des tables pour les catalogues. Mais il y a une différence significative. Pour les produits, vous pouvez créer de nouveaux attributs via le panneau d'administration - il s'agit de la fonctionnalité Magento par défaut prête à l'emploi. Si Magento ne fournit que des structures de données EAV pour d'autres entités en fonction de leur remplissage de logiciel, alors pour les produits, une interface est implémentée qui vous permet de le faire au niveau de l'utilisateur (gestionnaire de magasin) - Magasins / Attributs / Produit .
Pour les produits, il existe deux autres tableaux liés à l'EAV:
eav_attribute_seteav_attribute_group
Dans l'ensemble, ils sont plus susceptibles d'afficher des informations que de les stocker. Les attributs de produit sont combinés dans un set et, lors de la création d'un produit, un ensemble d'attributs lui est attribué, ce qui permet de remplir une carte de produit pour, par exemple, un téléviseur, de choisir un ensemble d'attributs liés spécifiquement aux appareils électroménagers (ou même pour un groupe de produits appelés "téléviseurs"). La fusion d'attributs en ensembles se produit dans les magasins / attributs / produit / ensemble d'attributs :
Total
À mon humble avis, Magento est un bon exemple du fait que la pertinence d'utiliser l'EAV est assez étroite. Lorsque vous marquez l'utilisation d'EAV pour 8 entités ( eav_entity_type ), la notation EAV n'est utilisée que pour 4 entités ( eav_attribute ), dont seulement 2 entités ont des attributs EAV véritables - catalog_category et catalog_product . De plus, pour catalog_category attributs EAV ne sont pas utilisés pour leur destination (un grand nombre d'attributs différents pour décrire une entité avec un petit nombre d'attributs liés à une seule instance ), mais pour la "localisation de vitrine" des valeurs d'attribut ( le même ensemble d'attributs pour une entité "catégorie de catalogue" avec la capacité d'un attribut d'instance d'avoir différentes significations pour différentes vitrines ).
La pleine utilisation d'EAV n'est utilisée que pour catalog_product (bien qu'il existe également un mélange de "localisation de vitrine", mais il s'agit d'une extension du modèle EAV, et non de sa profanation, comme c'est le cas avec les catégories). Mais avec les produits, Magento révèle l'EAV dans son intégralité - l'application Magento peut être utilisée en toute sécurité pour démontrer clairement les principes de l'EAV.