इस प्रकाशन में, मैं मैगेंटो 2 डेटा संरचनाओं की समीक्षा करूंगा जो ईएवी जैसी अवधारणा का समर्थन करते हैं। डेवलपर्स को कभी-कभी कोड के विकलों से बाहर निकलने और ईगल की उड़ान की ऊंचाई से अपने जीवन के स्थानों का सर्वेक्षण करने की आवश्यकता होती है - यह आपको उन चीजों पर ध्यान केंद्रित करने की अनुमति देता है जो वास्तव में महत्वपूर्ण हैं या बस बड़ी हैं। तो मैं बाहर निकला।

संक्षिप्त नाम EAV को Entity - Attribute - Value (यह उन लोगों के लिए है, जिन्होंने ऊपर दिए गए लिंक का पालन नहीं किया है)। ईएवी का मुख्य " लाभ " उन मामलों में डेटाबेस स्पेस का कुशल उपयोग है जहां विभिन्न विशेषताओं (गुणों, मापदंडों) की संभावित संख्या जो कि चीजों (संस्थाओं) का वर्णन करने के लिए उपयोग की जा सकती है, लेकिन विशेषताओं की संख्या, जो वास्तव में संदर्भित होती है व्यक्तिगत वस्तु अपेक्षाकृत छोटी होती है। ई-कॉमर्स में इस तरह के मामले का एक अच्छा उदाहरण "उत्पाद" की अवधारणा है - उत्पादों की महत्वपूर्ण विशेषताएं " टीवी " (स्क्रीन का आकार) उत्पादों के महत्वपूर्ण गुणों से अलग है " स्लीपिंग बैग " (न्यूनतम आरामदायक तापमान)।

तो मैगेंटो 2 ईएवी प्रारूप में डेटा संग्रहीत करने के लिए क्या प्रदान करता है?

'eav_' नामस्थान

eav_ Magento 2.3 डेटाबेस में, eav_ उपसर्ग के साथ 21 टेबल हैं। उन सभी को तीन समूहों में विभाजित किया जा सकता है:

• eav_attribute
• eav_entity
• eav_form

सबसे आसान तरीका eav_form साथ है - ये टेबल यूआई पर कुछ ईएवी डेटा के प्रदर्शन से संबंधित हैं और डेटाबेस में ईएवी डेटा के प्लेसमेंट से सीधे संबंधित नहीं हैं (मैं केवल डेटा संरचनाओं पर विचार करता हूं और केवल सूचना भंडारण के दृष्टिकोण से, इसका प्रदर्शन नहीं)। प्रयोग के लिए, मैंने डेटाबेस से eav_form स्पेस eav_form को डिलीट किया और इसने मुझे स्टोर में ऑर्डर रखने से नहीं रोका। तो आपको अभी भी यह देखने की आवश्यकता है कि इस टेबल स्पेस के डेटा का उपयोग कहां किया जाता है और मैगेंटो को कार्य करने के लिए इसकी कितनी आवश्यकता है।

शेष दो में से, eav_attribute समूह अक्षर A (ttribute) और eav_entity समूह को E (ntity) अक्षर को संदर्भित करता है। V (alue) अक्षर कहां है?

इकाई विशेषताओं के मान तालिका नाम प्रत्ययों में खोजे जाने चाहिए:

• _datetime
• _decimal
• _int
• _text
• _ varchar

आप देख सकते हैं कि तालिकाओं के साथ शुरू:

• catalog_category_entity_
• catalog_product_entity_
• customer_address_entity_
• customer_entity_
• eav_entity_

उपसर्गों की संख्या (5) के प्रत्ययों (5) की संख्या का एक सरल गुणन हमें कुल सारणी (25) देता है जिसमें मान डेटा संग्रहीत किया जाना चाहिए।

'eav_entity_type': इकाई प्रकार रजिस्ट्री

Magento में EAV की शुरुआत को eav_entity_type तालिका में eav_entity_type की eav_entity_type है। यह यहां है कि ईएवी संरचना में किस प्रकार के निकाय विशेषता मान संग्रहीत किए जाएंगे। तो, शुरू में Magento 2.3 निम्नलिखित आठ संस्थाओं के लिए यह विकल्प प्रदान करता है:

• customer
• customer_address
• catalog_category
• catalog_product
• order
• invoice
• creditmemo
• shipment

'eav_attribute': विशेषता रजिस्ट्री

अगला कदम यह पता लगाना है कि इस प्रकार की संस्थाएं किस विशेषता को चिह्नित कर सकती हैं। यह जानकारी eav_attribute तालिका में है। विशेषता रजिस्ट्री में विदेशी कुंजी द्वारा इकाई प्रकारों के रजिस्टर पर एक क्लोजर है। विशेषता रजिस्ट्री में, शुरू में 135 प्रविष्टियाँ 4 प्रकार की संस्थाओं से संबंधित हैं:

• customer
• customer_address
• catalog_category

• catalog_product

  
  

  ये कैसी बात कर रहा है? कम से कम, अन्य प्रकार की इकाइयाँ:

  
  
• order
• invoice
• creditmemo
• shipment

डेटा स्टोर करने के लिए EAV संरचना का उपयोग न करें। यही है, किसी समय, उत्साह मौजूद था और आठ प्रकार की संस्थाओं के लिए ईएवी के उपयोग की योजना बनाई गई थी, लेकिन वास्तव में वे 4 पर रुक गए।

v eav_entity_ ’: भूत स्थान

eav_entity टेबल eav_entity चीनी भूत शहरों से मिलता-जुलता है - 9 स्पेस टेबल में से केवल दो में डेटा होता है:

• eav_entity_type : यह उन इकाई प्रकारों का एक रजिस्टर है, जिनका मैंने ऊपर उल्लेख किया है;
• eav_entity_attribute : समूहों में विशेषताओं को व्यवस्थित करने के लिए उपयोग किया जाता है (उनके भंडारण की तुलना में डेटा के प्रदर्शन के करीब); यह जानकारी सीधे तौर पर संस्थाओं की तुलना में खुद से अधिक सीधे संबंधित है (यानी, स्पष्ट रूप से इस पल्ली से नहीं - यह eav_attribute_ space में एक जगह है);

शेष 7 टेबल खाली हैं:

• eav_entity
• eav_entity_datetime
• eav_entity_decimal
• eav_entity_int
• eav_entity_store
• eav_entity_text
• eav_entity_varchar

यह प्रत्येक प्रकार की इकाई के लिए संबंधित प्रत्ययों के साथ 5 तालिकाओं के बजाय तालिकाओं के एक सेट में तालिका विशेषताओं ( datetime , decimal , int , text , varchar ) के लिए मानों को संग्रहीत करने के तरीके को एकजुट करने की कोशिश करने के समान है। असफल प्रयास पर? या यह Magento में ईएवी का भविष्य है?

किसी भी तरह से, पृथ्वी निराकार और खाली थी, और अंधकार रसातल और भगवान की आत्मा के ऊपर था इन तालिकाओं का प्रारंभ में उपयोग नहीं किया जाता है।

गुण मान टाइप करें

eav_entity_type प्रकारों को eav_attribute तालिका में सेट किया गया है, eav_attribute स्वयं को और उनकी अनुवर्ती इकाई प्रकारों को eav_attribute करने के लिए eav_attribute तालिका में सेट किए गए हैं। और यह कैसे निर्धारित किया जाए कि ऐसी इकाई की ऐसी विशेषता के लिए मूल्य कहां देखें?

eav_attribute.backend_type फ़ील्ड हमें इसमें मदद करेगी। यह दिखाता है कि विशेषता मान कहाँ संग्रहीत हैं:

• स्थैतिक : अपने आप में इकाई के बारे में डेटा के साथ तालिका में (उदाहरण के लिए, # 9 मान के लिए मान - customer.email , आपको email कॉलम में customer_entity तालिका में खोज करने की आवश्यकता है);

शेष प्रकारों के लिए, मानों को अलग-अलग तालिकाओं में संग्रहित किया जाता है, जिनके नाम में उपसर्ग इकाई के प्रकार ( customer_ , ...) से मेल खाती है और डेटा प्रकारों में से एक में प्रत्यय:

• datetime
• decimal
• int
• text
• varchar

अर्थात, टाइप 79 catalog_product.special_from_date प्रकारों के मानों को टेबल catalog_product_entity_datetime में संग्रहित किया जाता है। विशेषता के लिए मान # 77 catalog_product.price catalog_product_entity_decimal टेबल में हैं।

मूल्य प्रकारों के संबंध में eav_attribute तालिका में क्या देखना दिलचस्प है? जैसा कि मैंने ऊपर उल्लेख किया है, इस तालिका में eav_entity_type में पंजीकृत 8 इकाई प्रकारों में से केवल 4 के लिए विशेषताओं का वर्णन है। इसी समय, customer और customer_address जैसी संस्थाओं के लिए customer_address शुरू में परिभाषित की गई सभी विशेषताएँ static मूल्य प्रकार की हैं - अर्थात, वे तालिका में साधारण कॉलम हैं और EAV दृष्टिकोण का लाभ नहीं उठाती हैं। टेबल:

• 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

शुरू में खाली हैं और केवल प्रोग्रामेटिक रूप से उपयोग किया जा सकता है (यानी, व्यवस्थापक पैनल के माध्यम से, तीसरे पक्ष के एक्सटेंशन के बिना, इन तालिकाओं के लिए कुछ भी लिखने का कोई तरीका नहीं है)।

श्रेणियों के लिए ई.ए.वी.

कैटलॉग श्रेणियां - यह पहली इकाई है जो मैगेंटो में ईएवी दृष्टिकोण का कम या ज्यादा उपयोग करती है। इकाई प्रकार catalog_category , प्रारंभिक विशेषताओं का कुल 30 है, जिनमें से गैर-स्थैतिक - 26 है। यह है, केवल 4 विशेषताओं ( children_count के level , level , path , position ) के catalog_category_entity को catalog_category_entity में संग्रहित किया जाता catalog_category_entity बाकी catalog_category_entity_ में संग्रहीत हैं decimal | int | text | varchar ]।

इस सेट से तालिकाओं की संरचना दोनों एक दूसरे से और समान प्रकार की अन्य संस्थाओं (क्लाइंट, उनके पते, आदि) की तालिकाओं के समान है:

 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`), ... ) ... 

विभिन्न प्रकार के संग्रहीत मूल्यों ( datetime , decimal , int , text , varchar ) के लिए, केवल value स्तंभ का प्रकार बदलता है। यह संरचना आपको अलग स्टोरफ्रंट ( store_id ) के लिए एक अलग इकाई ( entity_id ) के एक अलग attribute_id ( entity_id ) के एक अलग मूल्य ( value ) को बचाने की अनुमति देती है।

store_id की वास्तुकला सुविधाओं के संबंध में, स्टोरफ्रंट के साथ एक अतिरिक्त कनेक्शन store_id - store_id । इस प्रकार, अलग-अलग स्टोरफ्रंट के लिए एक ही इकाई के समान गुण के मूल्यों का स्थानीयकरण करना संभव है। मैगेंटो में कैटलॉग श्रेणियां पहली इकाइयां हैं जिनके लिए आप सीधे बॉक्स से ईएवी सबसिस्टम का उपयोग कर सकते हैं। आप व्यवस्थापक पैनल के माध्यम से निर्देशिका विशेषताओं के लिए मान सेट कर सकते हैं।

आप न केवल पाठ विशेषताओं के लिए अलग-अलग मान दे सकते हैं, संबंधित स्टोरफ्रंट की भाषा में अनुवाद कर सकते हैं, बल्कि अन्य प्रकारों की विशेषताओं को भी स्थानीय बना सकते हैं। उदाहरण के लिए, विशेषता catalog_category.custom_design_from लिए स्टोर स्टोरफ्रंट पर क्रिसमस की छुट्टियों की पूर्व संध्या पर आप अगले साल के 7 जनवरी को मान सेट कर सकते हैं, और इसके 24 दिसंबर को एन स्टोर के सामने।

उत्पादों के लिए ई.ए.वी.

सामान्य तौर पर, यह उसी प्रकार की इकाई है जिसके लिए ईएवी को Magento में लॉन्च किया गया था। इकाई प्रकार कुल प्रारंभिक विशेषताओं का catalog_product - 63, जिनमें से गैर-स्थैतिक - 56। उत्पादों के लिए ईएवी का समर्थन करने वाली तालिकाओं की संरचना कैटलॉग के लिए तालिकाओं की संरचना के समान है। लेकिन एक महत्वपूर्ण अंतर है। उत्पादों के लिए, आप व्यवस्थापक पैनल के माध्यम से नई विशेषताएँ बना सकते हैं - यह बॉक्स से बाहर डिफ़ॉल्ट मैगनेटो कार्यक्षमता है। यदि मैगेंटो अपने सॉफ्टवेयर भरने के आधार पर अन्य संस्थाओं के लिए केवल ईएवी डेटा संरचना प्रदान करता है, तो उत्पादों के लिए एक इंटरफ़ेस लागू किया जाता है जो आपको उपयोगकर्ता स्तर (स्टोर मैनेजर) - स्टोर / एट्रीब्यूट्स / उत्पाद पर ऐसा करने की अनुमति देता है।

उत्पादों के लिए, EAV से संबंधित दो और तालिकाएँ हैं:

• eav_attribute_set
• eav_attribute_group

द्वारा और बड़े, वे इसे संग्रहीत करने की तुलना में जानकारी प्रदर्शित करने की अधिक संभावना रखते हैं। उत्पाद विशेषताओं को एक set में जोड़ा जाता है और जब एक उत्पाद बनाया जाता है, तो विशेषताओं का एक सेट उसे सौंपा जाता है, जो उदाहरण के लिए, एक टीवी सेट के लिए एक उत्पाद कार्ड को भरने की अनुमति देता है, विशेष रूप से घरेलू उपकरणों से संबंधित (या यहां तक ​​कि उत्पादों के टीवी समूह के लिए) एक सेट का चयन करता है। सेट में गुण जोड़ना स्टोर / गुण / उत्पाद / विशेषता सेट में होता है :

कुल मिलाकर

IMHO, Magento एक अच्छा उदाहरण है कि EAV का उपयोग करने की उपयुक्तता काफी संकीर्ण है। 8 संस्थाओं ( eav_entity_type ) के लिए EAV के उपयोग को बुकमार्क करते समय, EAV संकेतन का उपयोग केवल 4 संस्थाओं ( eav_attribute ) के लिए किया जाता है, जिनमें से केवल 2 संस्थाओं में ही EAV विशेषताएँ होती हैं - catalog_category और catalog_product । इसके अलावा, catalog_category लिए catalog_category -विशेषताओं का उपयोग उनके इच्छित उद्देश्य के लिए नहीं किया जाता है (एक उदाहरण से संबंधित छोटी संख्या के साथ एक इकाई का वर्णन करने के लिए विभिन्न विशेषताओं की एक बड़ी संख्या ), लेकिन विशेषता मूल्यों के "शोकेस स्थानीयकरण" के लिए ( एक इकाई के लिए विशेषताओं का एक ही सेट) "कैटलॉग श्रेणी" एक उदाहरण विशेषता की क्षमता के साथ अलग-अलग स्टोरफ्रंट के लिए अलग-अलग अर्थ हैं )।

catalog_product का पूरा उपयोग केवल catalog_product लिए किया जाता है (हालांकि "स्टोरफ्रंट स्थानीयकरण" का एक प्रवेश भी है, लेकिन यह ईएवी मॉडल का एक विस्तार है, और इसके अपवित्रता नहीं है, जैसा कि श्रेणियों के मामले में है)। लेकिन उत्पादों के साथ मैगेंटो ईएवी को पूर्ण रूप से प्रकट करता है - मैगेंटो-एप्लिकेशन को ईएवी के सिद्धांतों को स्पष्ट रूप से प्रदर्शित करने के लिए सुरक्षित रूप से उपयोग किया जा सकता है।