قاعدة بيانات قيمة سمة الكيان مقابل قاعدة بيانات قيمة سمة الكياننموذج علائقي صارم للتجارة الإلكترونية

Question

ومن الآمن أن نقول أن إيف/كر نموذج قاعدة البيانات سيء.هكذا قال،

سؤال: ما هو نموذج قاعدة البيانات أو التقنية أو النمط الذي يجب استخدامه للتعامل مع "فئات" السمات التي تصف منتجات التجارة الإلكترونية والتي يمكن تغييرها في وقت التشغيل؟

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

هناك ميزة مشتركة لطيفة بين تطبيقات التجارة الإلكترونية الجيدة حيث تعرض مجموعة من المنتجات، ثم تحتوي على قوائم جانبية "للتنقل لأسفل" حيث يمكنك رؤية "دقة التلفزيون" كرأس، وأهم خمسة قرارات تلفزيونية شائعة بالنسبة لـ وجدت مجموعة.ما عليك سوى النقر فوق أحدها وسيظهر فقط أجهزة التلفاز ذات الدقة تلك، مما يسمح لك بالتعمق بشكل أكبر عن طريق تحديد فئات أخرى في القائمة الجانبية.ستكون هذه الخيارات هي سمات المنتج الديناميكية التي تتم إضافتها في وقت التشغيل.

مزيد من المناقشة:

قصة طويلة جدًا، مختصرة، هل هناك أي روابط على الإنترنت أو أوصاف نماذج يمكنها إصلاح الإعداد التالي "أكاديميًا"؟ أشكر نويل كينيدي لاقتراح جدول الفئات، ولكن الحاجة قد تكون أكبر من ذلك.أصفها بطريقة مختلفة أدناه، في محاولة لتسليط الضوء على أهميتها.قد أحتاج إلى تصحيح وجهة النظر لحل المشكلة، أو قد أحتاج إلى التعمق أكثر في EAV/CR.

أحب الاستجابة الإيجابية لنموذج EAV/CR.يقول جميع زملائي المطورين ما تطرق إليه جيفري كيمب أدناه:"يجب أن يتم تصميم وتصميم الكيانات الجديدة من قبل محترف" (أخرجت من السياق، اقرأ رده أدناه).المشكلة هي:

• تقوم الكيانات بإضافة وإزالة السمات أسبوعيًا
  (الكلمات الرئيسية للبحث تملي السمات المستقبلية)
• وصول كيانات جديدة أسبوعيا
  (يتم تجميع المنتجات من أجزاء)
• الكيانات القديمة تختفي أسبوعيا
  (مؤرشفة، أقل شهرة، موسمية)

يريد العميل إضافة سمات إلى المنتجات لسببين:

• القسم / البحث عن الكلمات الرئيسية / مخطط المقارنة بين المنتجات المشابهة
• تكوين المنتج الاستهلاكي قبل الخروج

يجب أن تكون للسمات أهمية، وليس مجرد البحث عن الكلمات الرئيسية.إذا أرادوا مقارنة جميع الكعكات التي تحتوي على "كريمة الزينة المخفوقة"، فيمكنهم النقر على الكعك، والنقر على موضوع عيد الميلاد، والنقر على زينة الكريمة المخفوقة، ثم التحقق من جميع الكعكات المثيرة للاهتمام مع العلم أن جميعها تحتوي على زينة الكريمة المخفوقة.وهذا ليس خاصا بالكعك، مجرد مثال.

Answer 1

هناك بعض الإيجابيات والسلبيات العامة التي يمكنني التفكير فيها، وهناك مواقف يكون فيها أحدهما أفضل من الآخر:

الخيار 1، نموذج EAV:

• طليعة:وقت أقل لتصميم وتطوير تطبيق بسيط
• طليعة:كيانات جديدة يسهل إضافتها (قد يضاف المستخدمون؟)
• طليعة:مكونات الواجهة "العامة".
• يخدع:رمز معقد مطلوب للتحقق من صحة أنواع البيانات البسيطة
• يخدع:SQL أكثر تعقيدًا لتقارير بسيطة
• يخدع:يمكن أن تصبح التقارير المعقدة شبه مستحيلة
• يخدع:أداء ضعيف لمجموعات البيانات الكبيرة

الخيار 2، نمذجة كل كيان على حدة:

• يخدع:مزيد من الوقت اللازم لجمع المتطلبات والتصميم
• يخدع:يجب أن تصمم كيانات جديدة وتصميمها من قبل محترف
• يخدع:مكونات واجهة مخصصة لكل كيان
• طليعة:قيود نوع البيانات والتحقق من صحتها سهلة التنفيذ
• طليعة:SQL سهلة الكتابة وسهلة الفهم والتصحيح
• طليعة:حتى التقارير الأكثر تعقيدًا تكون بسيطة نسبيًا
• طليعة:أفضل أداء لمجموعات البيانات الكبيرة

الخيار 3، المجموعة (الكيانات النموذجية "بشكل صحيح"، ولكن أضف "امتدادات" للسمات المخصصة لبعض/جميع الكيانات)

• برو / كون:يتطلب الأمر وقتًا أطول لجمع المتطلبات والتصميم مقارنة بالخيار 1 ولكن ربما ليس بنفس القدر الذي يتطلبه الخيار 2 *
• يخدع:يجب أن يتم تصميم وتصميم الكيانات الجديدة بواسطة محترف
• طليعة:يمكن إضافة سمات جديدة بسهولة لاحقًا
• يخدع:رمز معقد مطلوب للتحقق من صحة أنواع البيانات البسيطة (للسمات المخصصة)
• يخدع:لا تزال مكونات الواجهة المخصصة مطلوبة، ولكن قد تكون مكونات الواجهة العامة ممكنة للسمات المخصصة
• يخدع:تصبح SQL معقدة بمجرد تضمين أي سمة مخصصة في التقرير
• يخدع:أداء جيد بشكل عام، إلا إذا كنت بحاجة إلى البحث حسب السمات المخصصة أو الإبلاغ عنها

* لست متأكدًا مما إذا كان الخيار 3 سيوفر بالضرورة أي وقت في مرحلة التصميم.

أنا شخصياً أميل إلى الخيار 2، وتجنب EAV حيثما أمكن ذلك.ومع ذلك، بالنسبة لبعض السيناريوهات، يحتاج المستخدمون إلى المرونة التي تأتي مع EAV؛ولكن هذا يأتي بتكلفة كبيرة.

Answer 2

من الآمن أن نقول أن نموذج قاعدة بيانات EAV/CR سيئ.

لا ليس كذلك.إنه مجرد استخدام غير فعال لقواعد البيانات العلائقية.يعمل متجر المفاتيح/القيمة البحتة بشكل رائع مع هذا النموذج.

والآن إلى سؤالك الحقيقي:كيفية تخزين السمات المختلفة وإبقائها قابلة للبحث؟

مجرد استخدام إيف.في حالتك سيكون جدول إضافي واحد.فهرسة على كل من اسم السمة وقيمتها، فإن معظم RDBMs تستخدم ضغط البادئة لتكرار اسم السمة، مما يجعلها سريعة ومضغوطة حقًا.

يصبح EAV/CR قبيحًا عند استخدامه لاستبدال الحقول "الحقيقية".كما هو الحال مع كل أداة، الإفراط في استخدامها أمر "سيء"، ويعطيها صورة سيئة.

Answer 3

// At this point, I'd like to take a moment to speak to you about the Magento/تنسيق أدوبي PSD.
// Magento/PSD is not a good ecommerce platform/شكل. Magento/PSD is not even a bad ecommerce platform/شكل. Calling it such would be an
// insult to other bad ecommerce platform/التنسيقات, such as Zencart or OsCommerce. No, Magento/PSD is an abysmal ecommerce platform/شكل. Having
// worked on this code for several weeks now, my hate for Magento/PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

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

العالم الحقيقي:أنا أعمل على تطبيق للبرامج الوسيطة وإليك أحد الاستعلامات للحصول على معلومات العنوان.

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

معلومات العنوان الدقيقة للنظام، بتكاسل

--

ملخص: استخدم Magento فقط إذا:

1. يتم إعطاؤك أكياسًا كبيرة من المال
2. يجب عليك أن
3. استمتع بالألم

Answer 4

أنا مندهش أنه لم يذكر أحد قواعد بيانات NoSQL.

لم أمارس مطلقًا NoSQL في سياق الإنتاج (اختبرت للتو MongoDB وأعجبت به) ولكن الهدف الأساسي من NoSQL هو القدرة على حفظ العناصر بسمات مختلفة في نفس "المستند".

Answer 5

عندما لا يكون الأداء متطلبًا رئيسيًا، كما هو الحال في نوع تطبيقات ETL، تتمتع EAV بميزة أخرى مميزة:يحفظ التفاضلية.

لقد قمت بتنفيذ عدد من التطبيقات حيث كان المطلب الشامل هو القدرة على رؤية محفوظات كائن المجال من "الإصدار" الأول إلى حالته الحالية.إذا كان كائن المجال هذا يحتوي على عدد كبير من السمات، فهذا يعني أن كل تغيير يتطلب إدراج صف جديد في الجدول المقابل له (ليس تحديثًا لأن السجل سيفقد، ولكن إدراج).لنفترض أن كائن المجال هذا هو شخص، ولدي 500 ألف شخص لتتبعهم بمتوسط ​​يزيد عن 100 تغيير خلال دورة حياة الأشخاص إلى سمات مختلفة.أضف إلى ذلك حقيقة أن التطبيق النادر هو الذي يحتوي على كائن مجال رئيسي واحد فقط، وسوف تستنتج بسرعة أن حجم قاعدة البيانات سوف يخرج عن نطاق السيطرة بسرعة.

الحل السهل هو حفظ التغييرات التفاضلية لكائنات المجال الرئيسية فقط بدلاً من حفظ المعلومات الزائدة عن الحاجة بشكل متكرر.

تتغير جميع النماذج بمرور الوقت لتعكس احتياجات العمل الجديدة.فترة.إن استخدام EAV ليس سوى إحدى الأدوات الموجودة في صندوقنا للاستخدام؛ولكن لا ينبغي أبدًا تصنيفها تلقائيًا على أنها "سيئة".

Answer 6

أنا أعاني من نفس المشكلة.قد يكون من المثير للاهتمام بالنسبة لك الاطلاع على المناقشة التالية حول اثنين من حلول التجارة الإلكترونية الحالية:Magento (EAV) وJoomla (البنية العلائقية العادية):https://forum.virtuemart.net/index.php?topic=58686.0

يبدو أن أداء EAV الخاص بـ Magento يعد رائعًا حقًا.

لهذا السبب أنا أميل نحو الهيكل الطبيعي.للتغلب على نقص المرونة، أفكر في إضافة قاموس بيانات منفصل في المستقبل (XML أو جداول قاعدة بيانات منفصلة) يمكن تحريره، وبناءً على ذلك، سيكون رمز التطبيق لعرض فئات المنتجات ومقارنتها بمجموعة السمات الجديدة هو تم إنشاؤها، جنبا إلى جنب مع البرامج النصية SQL.

يبدو أن مثل هذه الهندسة المعمارية هي النقطة المثالية في هذه الحالة - فهي مرنة وفعالة في نفس الوقت.

قد تكون المشكلة هي الاستخدام المتكرر لـ ALTER TABLE في البيئة الحية.أنا أستخدم Postgres، لذا نأمل أن يؤدي MVCC وDDL للمعاملات إلى تخفيف الألم.

Answer 7

ما زلت أصوت لصالح النمذجة على المستوى الذري الأقل أهمية لـ EAV.اسمح للمعايير والتقنيات والتطبيقات الموجهة نحو مجتمع مستخدم معين بتحديد نماذج المحتوى واحتياجات التكرار للسمات والحبوب وما إلى ذلك.

Answer 8

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

أحد الحلول هو استخدام قاعدة بيانات SQL/نموذج EAV فقط لجانب الإدارة/التحرير في كتالوج المنتج والحصول على بعض العمليات التي تعمل على إلغاء تطبيع المنتجات إلى شيء يجعلها قابلة للبحث.نظرًا لأن لديك سمات بالفعل، ومن ثم فمن المحتمل أنك تريد الواجهة، فقد يكون هذا الشيء Solr أو ElasticSearch.يتجنب هذا الأسلوب بشكل أساسي جميع الجوانب السلبية لنموذج EAV ويقتصر التعقيد الإضافي على إجراء تسلسل لمنتج كامل إلى JSON عند التحديث.

Answer 9

EAV له عيوب عديدة:

1. تدهور الأداء بمرور الوقت بمجرد أن يتجاوز حجم البيانات في التطبيق حجمًا معينًا ، من المحتمل أن يصبح استرجاع هذه البيانات ومعالجتها أقل كفاءة.
2. استعلامات SQL معقدة للغاية ويصعب كتابتها.
3. مشاكل سلامة البيانات.لا يمكنك تحديد المفاتيح الخارجية لجميع الحقول المطلوبة.
4. يجب عليك تحديد البيانات الوصفية الخاصة بك والحفاظ عليها.

Answer 10

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

انا صنعت مجموعة صغيرة من الاختبارات لقياس تصميمين:أحدهما يستخدم EAV، والآخر يستخدم Postgres ARRAY لتخزين بيانات الخلية.

إيف

مجموعة مصفوفة

يحتوي كلا المخططين على فهارس على الأعمدة المناسبة، ويتم استخدام الفهارس بواسطة المخطط.

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