في هذا المنشور ، سأراجع هياكل بيانات Magento 2 التي تدعم مفهومًا مثل EAV . يحتاج المطورون في بعض الأحيان إلى الخروج من مجموعة التعليمات البرمجية ومحاولة مسح أماكن حياتهم من ذروة رحلة النسر - وهذا يتيح لك التركيز على أشياء مهمة حقًا أو كبيرة جدًا. لذلك خرجت.

يتم الكشف عن اختصار EAV على أنه كيان - سمة - قيمة (هذا بالنسبة لأولئك الذين لم يتبعوا الرابط أعلاه). تتمثل " الميزة " الرئيسية لـ EAV في الاستخدام الفعال لمساحة قاعدة البيانات في الحالات التي يكون فيها عدد الخصائص المختلفة (الخصائص ، المعلمات) التي يمكن استخدامها لوصف الأشياء (الكيانات) واسعًا للغاية ، ولكن عدد السمات ، الذي يشير فعليًا إلى كائن فردي صغير نسبيا. مثال جيد على مثل هذه الحالة في التجارة الإلكترونية هو مفهوم "المنتج" - تختلف السمات المهمة للمنتجات " TV " (حجم الشاشة) عن السمات المهمة لمنتجات " حقيبة النوم " (درجة الحرارة المريحة الدنيا).

إذن ما الذي تقدمه Magento 2 لتخزين البيانات بتنسيق EAV؟

مساحة الاسم "eav_"

في قاعدة بيانات Magento 2.3 eav_ ، هناك 21 جدولًا يحتوي على البادئة eav_ . يمكن تقسيمهم جميعًا إلى ثلاث مجموعات:

• eav_attribute
• eav_entity
• eav_form

أسهل طريقة هي استخدام eav_form - تتعلق هذه الجداول بعرض بعض بيانات EAV على واجهة المستخدم ولا تتعلق مباشرة بوضع بيانات EAV في قاعدة البيانات (أعتبر فقط بنيات البيانات وفقط من وجهة نظر تخزين المعلومات ، وليس عرضها). للتجربة ، قمت بحذف eav_form الفضائية eav_form من قاعدة البيانات وهذا لم يمنعني من وضع طلب في المتجر. لذلك لا تزال بحاجة إلى البحث عن مكان استخدام البيانات من مساحة الجدول هذه والمقدار المطلوب لتشغيل Magento.

من المجموعتين المتبقيتين ، تشير مجموعة eav_attribute إلى الحرف A (ttribute) ، ومجموعة eav_entity إلى الحرف E (ntity) . أين هو الحرف الخامس (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': سجل نوع الكيان

يجب العثور على بداية EAV في Magento في جدول eav_entity_type . وهنا يحدد أنواع قيم سمات الكيانات التي سيتم تخزينها في بنية EAV. لذلك ، في البداية يقدم 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 لتخزين البيانات. هذا هو ، في مرحلة ما ، كان الحماس موجودًا وتم التخطيط لاستخدام EAV لثمانية أنواع من الكيانات ، لكنها في الواقع توقفت عند 4.

'eav_entity_': مساحة الأشباح

تشبه eav_entity الجدول eav_entity مدن الأشباح الصينية - من بين 9 طاولات فضائية ، يوجد في جدولين فقط بيانات:

• eav_entity_type : هذا سجل لأنواع الكيانات التي ذكرتها أعلاه ؛
• eav_entity_attribute : يستخدم لتنظيم السمات في مجموعات (أقرب إلى عرض البيانات من تخزينها) ؛ تتعلق هذه المعلومات بشكل مباشر بالسمات نفسها أكثر من الكيانات (أي من الواضح أنها ليست من هذه الرعية - لها مكان في مساحة eav_attribute_ ) ؛

الجداول 7 المتبقية فارغة:

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

إنه مشابه جدًا لمحاولة توحيد طريقة تخزين القيم لسمات الكيان في مجموعة واحدة من الجداول ( datetime ، decimal ، int ، text ، varchar ) بدلاً من احتواء 5 جداول مع اللواحق المقابلة لكل نوع من الكيانات. في محاولة فاشلة؟ أم هو مستقبل EAV في Magento؟

على أي حال كانت الأرض عديمة الشكل وفارغة ، وكان الظلام فوق الهاوية ، وروح الله لا يتم استخدام هذه الجداول في البداية.

أنواع قيمة السمة

يتم تعيين أنواع eav_entity_type في جدول eav_attribute ، eav_attribute تعيين السمات نفسها eav_attribute لأنواع الكيانات المقابلة في جدول eav_attribute . وكيف يمكن تحديد مكان البحث عن قيمة هذه السمة لمثل هذا الكيان؟

eav_attribute.backend_type الحقل eav_attribute.backend_type . يوضح مكان تخزين قيم السمات:

• ثابت : في الجدول الذي يحتوي على بيانات حول الكيان نفسه (على سبيل المثال ، قيم السمة رقم 9 - customer.email ، تحتاج إلى البحث في جدول customer_entity في عمود email ) ؛

بالنسبة للأنواع المتبقية ، يتم تخزين القيم في جداول منفصلة ، حيث تتوافق البادئة مع نوع الكيان ( customer_ ، ...) واللاحقة لاحد أنواع البيانات:

• datetime
• decimal
• int
• text
• varchar

بمعنى ، يتم تخزين قيم السمة # 79 catalog_product.special_from_date نوع datetime في الجدول catalog_product_entity_datetime . قيم السمة # 77 catalog_product.price موجودة في الجدول catalog_product_entity_decimal .

ما هو المثير للاهتمام في جدول eav_attribute فيما يتعلق بأنواع القيمة؟ كما أشرت أعلاه ، يصف هذا الجدول السمات الخاصة بـ 4 فقط من أنواع الكيانات الـ 8 المسجلة في eav_entity_type . في الوقت نفسه ، بالنسبة إلى كيانات مثل customer و 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

تكون فارغة في البداية ولا يمكن استخدامها إلا برمجيًا (على سبيل المثال ، من خلال لوحة المشرف ، بدون ملحقات الطرف الثالث ، لا توجد وسيلة لكتابة أي شيء على هذه الجداول).

EAV للفئات

فئات الكتالوج - هذا هو الكيان الأول الذي يستخدم أكثر أو أقل منهج EAV في Magento. نوع الكيان هو catalog_category ، إجمالي السمات الأولية هو 30 ، منها غير ثابت - 26. أي ، يتم تخزين قيم 4 سمات فقط ( children_count ، level ، path ، position ) في الجدول catalog_category_entity ، يتم تخزين الباقي في catalog_category_entity_ [ datetime | 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 . تتيح لك هذه البنية حفظ قيمة ( value ) منفصلة لسمة منفصلة ( attribute_id ) لكيان منفصل ( entity_id ) لواجهة store_id منفصلة ( store_id ).

فيما يتعلق بالسمات المعمارية لـ Magento ، تتم إضافة اتصال إضافي store_id - store_id . وبالتالي ، فمن الممكن توطين قيم نفس السمة لنفس الكيان لواجهات المتاجر المختلفة. فئات الكتالوج هي الكيانات الأولى في Magento التي يمكنك من خلالها استخدام نظام EAV الفرعي مباشرة من خارج الصندوق. يمكنك تعيين قيم لسمات الدليل من خلال لوحة المسؤول.

لا يمكنك فقط إعطاء قيم مختلفة لسمات النص ، والترجمة إلى لغة واجهة المتجر المقابلة ، ولكن يمكنك أيضًا ترجمة سمات الأنواع الأخرى. على سبيل المثال ، تحسبًا لقضاء عطلة عيد الميلاد على واجهة متجر ru للحصول على السمة catalog_category.custom_design_from يمكنك تعيين القيم في 7 يناير من العام المقبل ، وعلى واجهة المتجر في 24 ديسمبر من هذا.

EAV للمنتجات

بشكل عام ، هذا هو نفس نوع الكيان الذي تم إطلاق EAV له في Magento. نوع الكيان هو catalog_product ، من إجمالي السمات الأولية - 63 ، منها غير ثابتة - 56. يشبه هيكل الجداول التي تدعم EAV للمنتجات هيكل بنية الجداول للكتالوجات. ولكن هناك فرق كبير واحد. بالنسبة للمنتجات ، يمكنك إنشاء سمات جديدة من خلال لوحة المسؤول - هذه هي وظيفة Magento الافتراضية خارج الصندوق. إذا كانت Magento لا توفر سوى هياكل بيانات EAV للكيانات الأخرى بناءً على ملء البرامج الخاصة بها ، فبالنسبة للمنتجات ، يتم تنفيذ واجهة تتيح لك القيام بذلك على مستوى المستخدم (مدير المتجر) - المتاجر / السمات / المنتج .

بالنسبة للمنتجات ، هناك جدولان آخران يتعلقان بـ EAV:

• eav_attribute_set
• eav_attribute_group

بشكل عام ، من المرجح أن يعرضوا المعلومات بدلاً من تخزينها. يتم دمج سمات المنتج في set ، وعند إنشاء منتج ، يتم تعيين مجموعة من السمات لها ، والتي تسمح بملء بطاقة المنتج ، على سبيل المثال ، للتلفزيون ، واختيار مجموعة من السمات المتعلقة بالأجهزة المنزلية (أو حتى بمجموعة من المنتجات تسمى "TVs"). يحدث دمج السمات في مجموعات في مجموعة المتاجر / السمات / المنتج / مجموعة السمات :

المجموع

IMHO ، Magento هو مثال جيد على حقيقة أن ملاءمة استخدام EAV ضيقة للغاية. عند وضع إشارة مرجعية على استخدام EAV لـ 8 كيانات ( eav_entity_type ) ، يتم استخدام تدوين EAV فقط لـ 4 كيانات ( eav_attribute ) ، منها كيانان فقط لهما سمات EAV حقيقية - catalog_category و catalog_product . علاوة على ذلك ، بالنسبة إلى catalog_category ، لا تُستخدم سمات EAV للغرض المقصود منها ( عدد كبير من السمات المختلفة لوصف كيان مع عدد صغير من السمات المتعلقة بمثيل واحد ) ، ولكن من أجل "توطين عرض" قيم السمات ( نفس مجموعة من السمات لكيان "فئة الكتالوج" مع إمكانية وجود سمة مثيل لها معان مختلفة لواجهات متاجر مختلفة ).

يستخدم الاستخدام الكامل لـ EAV فقط من أجل catalog_product (على الرغم من أن هناك أيضًا مزيج من "توطين واجهة المتجر" ، ولكن هذا امتداد لنموذج EAV ، وليس تدنيسًا ، كما هو الحال مع الفئات). ولكن مع منتجات Magento تكشف EAV بالكامل - يمكن استخدام Magento للتطبيق بأمان لإظهار مبادئ EAV بوضوح.