संपूर्ण गुण मान डेटाबेस बनाम सख्त संबंधपरक मॉडल ईकॉमर्स

Question

यह कहना सुरक्षित है कि EAV / CR डेटाबेस मॉडल खराब है। ने कहा कि,

प्रश्न: ई-कॉमर्स उत्पादों का वर्णन करने वाली विशेषताओं के "वर्गों" से निपटने के लिए कौन से डेटाबेस मॉडल, तकनीक या पैटर्न का उपयोग किया जाना चाहिए, जिसे रन टाइम में बदला जा सकता है?

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

अच्छे ई-कॉमर्स एप्स के बीच एक अच्छी आम सुविधा है जहां वे उत्पादों का एक सेट दिखाते हैं, फिर "ड्रिल डाउन" साइड मेन्यू लेते हैं जहां आप "टीवी रिज़ॉल्यूशन" को हेडर के रूप में देख सकते हैं, और शीर्ष पांच सबसे आम टीवी रिज़ॉल्यूशन के लिए। पाया गया। आप एक क्लिक करते हैं और यह केवल उस रिज़ॉल्यूशन के टीवी दिखाता है, जो आपको साइड मेनू पर अन्य श्रेणियों का चयन करके आगे ड्रिल करने की अनुमति देता है। ये विकल्प रन टाइम के दौरान जोड़े गए डायनामिक उत्पाद गुण होंगे।

आगे की चर्चा:

इतनी लंबी कहानी छोटी है, क्या इंटरनेट या मॉडल विवरण पर कोई लिंक है जो "अकादमिक" निम्नलिखित सेटअप को ठीक कर सकता है? मैं एक श्रेणी तालिका का सुझाव देने के लिए नोएल कैनेडी को धन्यवाद देता हूं, लेकिन आवश्यकता इससे अधिक हो सकती है। मैं नीचे एक अलग तरीके से वर्णन करता हूं, महत्व को उजागर करने की कोशिश कर रहा हूं। मुझे समस्या को हल करने के लिए एक दृष्टिकोण सुधार की आवश्यकता हो सकती है, या मुझे ईएवी / सीआर के लिए गहराई से जाने की आवश्यकता हो सकती है।

EAV / CR मॉडल की सकारात्मक प्रतिक्रिया से प्यार करें। मेरे साथी डेवलपर्स सभी कहते हैं कि जेफरी केम्प ने नीचे क्या छुआ है: "नई संस्थाओं को एक पेशेवर द्वारा मॉडलिंग और डिजाइन किया जाना चाहिए" (संदर्भ से बाहर, नीचे उनकी प्रतिक्रिया पढ़ें)। यह समस्या है:

• संस्थाएँ साप्ताहिक रूप से विशेषताएँ जोड़ और हटा देती हैं
  (खोज कीवर्ड भविष्य की विशेषताओं को निर्धारित करते हैं)
• नई संस्थाएँ साप्ताहिक रूप से पहुंचती हैं
  (उत्पादों को भागों से इकट्ठा किया जाता है)
• पुरानी संस्थाएं साप्ताहिक रूप से चली जाती हैं
  (संग्रहीत, कम लोकप्रिय, मौसमी)

ग्राहक दो कारणों से उत्पादों में विशेषता जोड़ना चाहते हैं:

• विभाग / कीवर्ड सर्च / उत्पादों के बीच तुलना चार्ट
• चेकआउट से पहले उपभोक्ता उत्पाद विन्यास

विशेषताओं का महत्व होना चाहिए, न कि केवल एक खोजशब्द खोज। यदि वे सभी केक की तुलना करना चाहते हैं, जिसमें "व्हीप्ड क्रीम फ्रॉस्टिंग" है, तो वे केक पर क्लिक कर सकते हैं, जन्मदिन की थीम पर क्लिक कर सकते हैं, व्हीप्ड क्रीम फ्रॉस्टिंग पर क्लिक कर सकते हैं, फिर उन सभी केक की जांच करें जो यह जानते हुए भी दिलचस्प हैं कि उन सभी ने क्रीम को गीला कर दिया है। यह केक के लिए विशिष्ट नहीं है, सिर्फ एक उदाहरण है।

Comments

आपके पास एक विदेशी कुंजी के साथ सिर्फ एक 'श्रेणी' तालिका क्यों नहीं हो सकती है?

— नोएल कैनेडी

ईएवी डेटाबेस मॉडल खराब है, यह कहना सुरक्षित या सटीक नहीं है, क्योंकि यह कुछ अनुप्रयोगों के लिए अनुकूल है।

— spencer7593

यदि आप विभिन्न संपत्तियों के साथ विभिन्न वस्तुओं को सजाते हैं, तो एंटिटी फ्रेमवर्क 4 में माता-पिता से विरासत में मिला है? यह उन वस्तुओं को कैसे बनाए रखता है?

— ज़ाचरी स्कॉट

EAV के एक चरम संस्करण पर आधारित एक सिस्टम के साथ एक सलाहकार के अनुभव के बारे में इस उत्कृष्ट लेख को इंगित करने के लिए बस वापस । इसे पढ़ें! simple-talk.com/opinion/opinion-pieces/bad-carma

— जेफरी केम्प

EAV एक बहुत व्यवहार्य डेटाबेस मॉडल है। मैं आपके जैसी समस्या पर काम कर रहा हूं और इसका हल ईएवी है। मैं निम्नलिखित लेख की सिफारिश करूंगा

— Sandor

Answer 1

कुछ सामान्य पेशेवरों और विपक्ष हैं जिनके बारे में मैं सोच सकता हूं, ऐसी परिस्थितियां हैं जहां एक दूसरे से बेहतर है:

विकल्प 1, ईएवी मॉडल:

• प्रो: एक साधारण अनुप्रयोग को डिजाइन और विकसित करने के लिए कम समय
• प्रो: जोड़ने के लिए आसान नई संस्थाओं (उपयोगकर्ताओं द्वारा भी जोड़ा जा सकता है?)
• प्रो: "जेनेरिक" इंटरफ़ेस घटक
• Con: सरल डेटा प्रकारों को मान्य करने के लिए आवश्यक जटिल कोड
• Con: सरल रिपोर्ट के लिए बहुत अधिक जटिल SQL
• Con: जटिल रिपोर्ट लगभग असंभव हो सकती हैं
• Con: बड़े डेटा सेट के लिए खराब प्रदर्शन

विकल्प 2, प्रत्येक इकाई को अलग से मॉडलिंग करना:

• Con: आवश्यकताओं और डिजाइन को इकट्ठा करने के लिए अधिक समय की आवश्यकता है
• Con: नई संस्थाओं को एक पेशेवर द्वारा मॉडलिंग और डिजाइन किया जाना चाहिए
• Con: प्रत्येक इकाई के लिए कस्टम इंटरफ़ेस घटक
• प्रो: डेटा प्रकार बाधाओं और सत्यापन को लागू करने के लिए सरल
• प्रो: SQL लिखना आसान है, समझना और डीबग करना आसान है
• प्रो: यहां तक ​​कि सबसे जटिल रिपोर्ट अपेक्षाकृत सरल हैं
• प्रो: बड़े डेटा सेट के लिए सर्वश्रेष्ठ प्रदर्शन

विकल्प 3, संयोजन (मॉडल इकाइयां "ठीक से", लेकिन कुछ / सभी संस्थाओं के लिए कस्टम विशेषताओं के लिए "एक्सटेंशन" जोड़ें)

• प्रो / Con: विकल्प 1 की तुलना में आवश्यकताओं और डिजाइन को इकट्ठा करने के लिए अधिक समय की आवश्यकता होती है, लेकिन शायद विकल्प 2 * जितना नहीं
• Con: नई संस्थाओं को एक पेशेवर द्वारा मॉडलिंग और डिजाइन किया जाना चाहिए
• प्रो: नई विशेषताओं को बाद में आसानी से जोड़ा जा सकता है
• Con: सरल डेटा प्रकार (कस्टम विशेषताओं के लिए) को मान्य करने के लिए आवश्यक जटिल कोड
• Con: कस्टम इंटरफ़ेस घटकों की अभी भी आवश्यकता है, लेकिन सामान्य इंटरफ़ेस घटक कस्टम विशेषताओं के लिए संभव हो सकते हैं
• Con: किसी भी कस्टम विशेषता को रिपोर्ट में शामिल करते ही SQL जटिल हो जाता है
• Con: अच्छा प्रदर्शन आमतौर पर, जब तक कि आपको कस्टम विशेषताओं द्वारा खोज या रिपोर्ट करने की आवश्यकता न हो

* मुझे यकीन नहीं है कि यदि विकल्प 3 आवश्यक रूप से डिजाइन चरण में किसी भी समय बचाएगा।

व्यक्तिगत रूप से मैं विकल्प 2 की ओर झुक जाता हूं, और जहां भी संभव हो वहां ईएवी से बच सकता हूं। हालांकि, कुछ परिदृश्यों के लिए उपयोगकर्ताओं को ईएवी के साथ आने वाले लचीलेपन की आवश्यकता होती है; लेकिन यह एक बड़ी लागत के साथ आता है।

Comments

क्या होगा यदि आपके पास पाठ मानों के लिए अनुक्रमित 1-n के साथ एक एकल तालिका थी, तो C # में (ram में) मैप करें कि आपको क्या चाहिए। यह अभी भी EAV की तरह काम करेगा, लेकिन "माचिस" डोमेन मॉडल होगा। क्रमबद्धता की तरह, लेकिन आप अनुक्रमित पाठ फ़ील्ड पर SQL चयन का उपयोग कर सकते हैं। प्रति रिकॉर्ड कोई एकाधिक चयन नहीं करता है। सभी "लागत" रैम में होती है।

— ज़ाचरी स्कॉट

@Zim, जो बहुत ज्यादा लगता है विकल्प 3। प्रत्येक पंक्ति में 1-n अतिरिक्त "जेनेरिक" कॉलम हैं, और उनमें संग्रहीत डेटा की व्याख्या आवेदन स्तर पर की जाती है। आपको एक स्थान पर एक रिकॉर्ड के लिए सभी डेटा होने का प्रदर्शन लाभ मिलता है। उन स्तंभों के बारे में मेटाडेटा को कहीं और संग्रहीत करने की आवश्यकता होती है, और यह वह जगह है जहां लागत ढोंगी होती है। निश्चित रूप से, हम मेटाडेटा को कैश कर सकते हैं RAM, लेकिन यह अभी भी डोमेन से सीधे आवेदन कोड में मॉडल किए जाने की तुलना में अधिक खर्च होता है। हालांकि एक फुलफिल्ड EAV मॉडल की तुलना में निश्चित रूप से बेहतर है!

— जेफरी केम्प

+10000 महान जवाब। आजकल लोग डेटाबेस डिजाइन और आवश्यकता को एकत्र करने में कंजूसी करते हैं। वे कोड के सौ गुना अधिक लाइनों को लिखेंगे, जो एक अच्छा डिज़ाइन बनाने के लिए समय लेते हैं।

— ट्यूलेंस कोर्डोवा

ईएवी विकल्प (1) की तुलना में आपको रिलेशनल ऑप्शन (2) के लिए अधिक डिज़ाइन की आवश्यकता नहीं है यदि आप केवल विकल्प 1 के स्ट्रेचर की आपूर्ति कर रहे हैं और रिलेशनल इंटरफ़ेस उस संरचना का वर्णन करने वाले मेटाडेटा से जेनेरिक है। यह सभी विकल्प 2 विपक्ष को हटा देता है। हालाँकि आप केवल वास्तविक Con को भूल गए हैं: DDL तालिकाओं को बहुत धीमा कर सकता है।

— फिलीपिक्सी

हाय @philipxy, मैंने "अधिक डिज़ाइन" नहीं कहा। EAV के लिए raison d'être यह है कि (संभवतः) सिस्टम डिज़ाइनर मॉडल को डिज़ाइन करने में कम समय बिता सकता है , इस डिज़ाइन के काम को बाद में "उपयोगकर्ताओं" के लिए छोड़ देता है (पेशेवर डिज़ाइन की कमी से विकल्प 1 के लिए सूचीबद्ध विपक्ष की ओर जाता है) । यदि ईएवी डिज़ाइनर के लिए कोई बचत नहीं करता है जो केवल ईएवी को हाथ से खारिज करने के लिए आग में अधिक ईंधन जोड़ता है। इसके अलावा, मैं असहमत हूं कि डीडीएल "बहुत धीमी है" - क्योंकि इसे केवल शायद ही कभी (मॉडल में त्रुटियों को ठीक करने के लिए, या नई सुविधाओं को लागू करने के लिए) की आवश्यकता होनी चाहिए, इसका प्रदर्शन अपेक्षाकृत महत्वहीन होना चाहिए।

— जेफरी केम्प

Answer 2

यह कहना सुरक्षित है कि EAV / CR डेटाबेस मॉडल खराब है।

नहीं यह नहीं। यह सिर्फ इतना है कि वे संबंधपरक डेटाबेस का एक अक्षम उपयोग हैं। इस मॉडल के साथ एक विशुद्ध रूप से की / वैल्यू स्टोर बढ़िया काम करता है।

अब, अपने वास्तविक प्रश्न के लिए: विभिन्न विशेषताओं को कैसे संग्रहीत करें और उन्हें खोज योग्य रखें?

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

ईएवी / सीआर बदसूरत हो जाता है जब आप इसका उपयोग 'वास्तविक' क्षेत्रों को बदलने के लिए करते हैं। हर उपकरण के साथ, यह अति 'बुरा' है, और यह एक खराब छवि देता है।

Comments

इसलिए सवाल यह है कि मेरे पास मेरी श्रेणियों में से एक के लिए 15 अतिरिक्त क्षेत्र हैं और ईआरवी मॉडल में यह 16 जोड़ + मुख्य तालिका बनाता है ताकि उत्पादों में खोज के लिए 16 बाएं जुड़ जाएं (और 16 जहां अगर कस्मर चाहते हैं) 3-4 मिलियन रिकॉर्ड में ( लोगों द्वारा सेकेंड हैंड उत्पाद बेचने के लिए एक वेबसाइट) ताकि यह कम हो?

— बाबक फगिहियन

यदि ये "अतिरिक्त क्षेत्र" पहले से ही परिभाषित हैं, तो यह निश्चित रूप से "वास्तविक क्षेत्र" के रूप में सबसे अच्छा होगा। और निश्चित रूप से, एक बड़ी क्वेरी में अनबाउंड संख्या में शामिल होना एक भारी टोल होगा (लेकिन अभी भी ठीक हो सकता है)। मैंने मेटाडेटा-हेवी प्रोजेक्ट पर जो भी किया है, वह है "मुख्य आइटम" के अनुसार "टैग" (ईएवी रिकॉर्ड के रूप में) की किसी भी संख्या की अनुमति देना, लेकिन "बड़ी क्वेरी" केवल कुछ पूर्वनिर्धारित tagnames चुनता है, जो कुल संख्या को सीमित रखता है (वर्तमान में ठेठ सिर्फ 4 टैग और लगभग 5 अन्य जॉइन हैं ), और जब उपयोगकर्ता एक विशिष्ट आइटम का चयन करता है, तो यह संबंधित सब कुछ प्राप्त करता है , लेकिन एक आइटम के लिए।

— जेवियर

लेकिन निश्चित रूप से, वह विशिष्ट प्रणाली वर्तमान में एक hstoreफ़ील्ड में पोर्ट की जा रही है (सिर्फ एक कारण कि हम PostgreSQL का उपयोग क्यों करते हैं)

— जेवियर

Answer 3

// इस बिंदु पर, मैं आपसे Magento / Adobe PSD प्रारूप के बारे में बात करने के लिए एक क्षण लेना चाहूंगा ।
// Magento / PSD एक अच्छा ईकॉमर्स प्लेटफॉर्म / प्रारूप नहीं है । Magento / PSD एक खराब ईकॉमर्स प्लेटफॉर्म / प्रारूप भी नहीं है । इसे ऐसे कॉल करना एक
// अन्य खराब ईकॉमर्स प्लेटफॉर्म / स्वरूपों का अपमान , जैसे कि Zencart या OsCommerce। जी नहीं, Magento / PSD एक मात्र ई-कॉमर्स मंच / है प्रारूप । बीत रहा है
// इस कोड पर अब कई हफ्तों तक काम किया गया, मैगेंटो के लिए मेरी नफरत PSD के एक उग्र आग में बढ़ गई है
// जो एक लाख सूर्यों के उग्र जुनून के साथ जलता है।

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. दर्द का आनंद लें

Comments

यह एक पुराना पोस्ट है, लेकिन मैं चाहता हूं कि मुझे यह 3 महीने पहले मिल गया था जब मैंने एक क्लाइंट के लिए एक Magento प्रोजेक्ट शुरू किया था। +1 दलदल / पेंट-शेकर सादृश्य के लिए!

— trevorc

सुंदर इंटरसेस्टिंग, मैगनेटो ऐसा लगता है जैसे ई-कॉमर्स सिस्टम के मामले में यह राजा-की-सड़क है। शायद केवल यह विपणन बहुत अच्छा है

— हेर

Magento रखरखाव स्तर के कारण लोकप्रिय नहीं है, लेकिन किसी को वास्तुकला में बदलाव या कुछ संशोधनों के बिना नई सुविधाओं को लागू करने की अनुमति देने के लिए अनुकूलित करने की क्षमता है। यह सुविधा लागत के साथ आती है।

— डिएगो मेंडेस

Magento 2 से दूर रहें यदि आप FE और BE दोनों के लिए ट्रिपल दर्द और अधिक दर्द से बचना चाहते हैं

— TheBlackBenzKid

Answer 4

मुझे आश्चर्य है कि किसी ने भी NoSQL डेटाबेस का उल्लेख नहीं किया है।

मैंने कभी भी उत्पादन के संदर्भ में NoSQL का अभ्यास नहीं किया है (बस MongoDB का परीक्षण किया गया था और प्रभावित हुआ था) लेकिन NoSQL का पूरा बिंदु एक ही "दस्तावेज़" में अलग-अलग विशेषताओं के साथ आइटम को सहेजने में सक्षम हो रहा है।

Comments

विचार करें कि MongoDB को लिखने के लिए डेटाबेस-स्तर लॉकिंग की आवश्यकता होती है , और समवर्ती उत्पादन यातायात के लिए इसका क्या मतलब है।

— बिल कार्विन

विचार करें कि लॉक की अवधि माइक्रोसेकंड के क्रम में है।

— हैलो वर्ल्ड

Answer 5

जहां प्रदर्शन एक प्रमुख आवश्यकता नहीं है, जैसा कि ईटीएल प्रकार के अनुप्रयोग में होता है, ईएवी का एक और विशिष्ट लाभ है: अंतर बचत।

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

एक आसान उपाय यह है कि निरर्थक सूचनाओं को बार-बार सहेजने के बजाय प्रमुख डोमेन ऑब्जेक्ट्स में केवल अंतर परिवर्तनों को बचाया जाए।

नई व्यावसायिक आवश्यकताओं को प्रतिबिंबित करने के लिए सभी मॉडल समय के साथ बदलते हैं। अवधि। ईएवी का उपयोग करना, लेकिन हमारे बॉक्स में उपयोग करने के लिए एक उपकरण है; लेकिन इसे कभी भी "खराब" के रूप में वर्गीकृत नहीं किया जाना चाहिए।

Comments

+1 के लिए "ईएवी का उपयोग करना, लेकिन उपयोग करने के लिए हमारे बॉक्स में एक उपकरण है; लेकिन इसे कभी भी" खराब "के रूप में वर्गीकृत नहीं किया जाना चाहिए।"

— कैच

Btw, इसे SCD (धीरे-धीरे बदलते आयाम) कहा जाता है। साथ ही बिटमैप की आवश्यकताएं (टाइप 4 एससीडी का एक विशिष्ट मामला) इस संपत्ति के लिए ईएवी स्कीमा के लिए कॉल करता है। याद रखें, NoSQL के 99% में कोई मूल जुड़ाव नहीं है, इसलिए यदि आपको इस प्रकार के डेटा के साथ "लाइव" जुड़ने की आवश्यकता है, तो ईएवी एकमात्र रास्ता है।

— चरवाहे

Answer 6

मैं उसी मुद्दे से जूझ रहा हूं। आपके लिए दो मौजूदा ईकॉमर्स समाधानों पर निम्नलिखित चर्चा की जाँच करना दिलचस्प हो सकता है: मैगेंटो (ईएवी) और जुमला (नियमित संबंधपरक संरचना): https://forum.virtuemart.net/index.php?topic/58686.0

ऐसा लगता है, कि Magento के EAV प्रदर्शन एक वास्तविक शोस्टॉपर है।

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

इस तरह की वास्तुकला इस मामले में मिठाई की तरह लगती है - एक ही समय में लचीला और प्रदर्शनकारी।

इस समस्या का लाइव वातावरण में ALTER TABLE का लगातार उपयोग हो सकता है। मैं Postgres का उपयोग कर रहा हूं, इसलिए इसका MVCC और ट्रांसेक्शनल DDL उम्मीद है कि दर्द को कम करेगा।

Answer 7

मैं अभी भी EAV के लिए सबसे कम-सार्थक परमाणु-स्तर पर मॉडलिंग के लिए वोट करता हूं। मानकों, प्रौद्योगिकियों और अनुप्रयोगों को दें जो सामग्री मॉडल, विशेषताओं, अनाज, आदि की पुनरावृत्ति आवश्यकताओं को तय करने के लिए कुछ उपयोगकर्ता समुदाय की ओर गियर करते हैं।

Answer 8

यदि यह केवल उत्पाद कैटलॉग विशेषताओं के बारे में है और इसलिए उन विशेषताओं के लिए सत्यापन की आवश्यकताएं सीमित हैं, तो ईएवी के लिए केवल वास्तविक नकारात्मक पक्ष प्रदर्शन है और यहां तक ​​कि केवल एक समस्या है जब आपकी क्वेरी कई "चीजों" (उत्पादों) के साथ विशेषताओं का सामना करती है, क्वेरी के लिए प्रदर्शन "मुझे id 234 के साथ उत्पाद के लिए सभी विशेषताएँ देता है" जबकि इष्टतम नहीं है अभी भी बहुत तेज है।

एक समाधान केवल उत्पाद सूची के व्यवस्थापक / संपादन पक्ष के लिए SQL डेटाबेस / ईएवी मॉडल का उपयोग करना है और कुछ प्रक्रिया है जो उत्पादों को किसी ऐसी चीज में विभाजित करती है जो इसे खोज योग्य बनाती है। चूँकि आपके पास पहले से ही विशेषताएँ हैं और इसलिए यह संभावना है कि आप मुखर करना चाहते हैं, यह कुछ Solr या ElasticSearch हो सकता है। यह दृष्टिकोण मूल रूप से ईएवी मॉडल के लिए सभी डाउनसाइड्स से बचा जाता है और जोड़ा जटिलता अद्यतन पर JSON के लिए एक संपूर्ण उत्पाद को सीमित करने तक सीमित है।

Answer 9

EAV में कई कमियां हैं:

1. समय के साथ प्रदर्शन में गिरावट एक बार जब एप्लिकेशन में डेटा की मात्रा एक निश्चित आकार से आगे बढ़ती है, तो उस डेटा की पुनर्प्राप्ति और हेरफेर कम और कम कुशल होने की संभावना है।
2. SQL क्वेरी बहुत जटिल है और लिखना मुश्किल है।
3. डेटा अखंडता समस्याओं। आप सभी आवश्यक क्षेत्रों के लिए विदेशी कुंजियों को परिभाषित नहीं कर सकते।
4. आपको अपनी स्वयं की मेटाडेटा को परिभाषित और बनाए रखना होगा।

Comments

1. यह सबसे संबंधपरक डेटाबेस के लिए भी सही है; यही कारण है कि शार्किंग का आविष्कार किया गया था। 2. डेटा मॉडलिंग जटिल और लागू करने में मुश्किल हो सकती है। मैंने ओएलएपी क्यूब स्कीमा परिवर्तनों के इंतजार में सप्ताह-महीने बिताए हैं। 3. पहले से ही अब ज्यादातर सॉफ्टवेयर में काम किया जाता है। 4. आपको यह "ईर्विन, एक्सेल और विसिओ" में करना है, जब भी किसी संबंधपरक योजनाबद्ध तरीके से मॉडलिंग करते हैं।

— चरवाहे

Answer 10

मुझे थोड़ी अलग समस्या है: विरल मूल्यों के साथ कई विशेषताओं के बजाय (जो संभवतः ईएवी का उपयोग करने का एक अच्छा कारण है), मैं एक स्प्रेडशीट की तरह कुछ और स्टोर करना चाहता हूं। शीट में कॉलम बदल सकते हैं, लेकिन एक शीट के भीतर सभी कोशिकाओं में डेटा होगा (विरल नहीं)।

मैंने परीक्षणों का एक छोटा सा सेट बनाया दो डिज़ाइनों को बेंचमार्क करने : एक ईएवी का उपयोग कर, और दूसरा एक पोस्टग्रैस एआरएवाई का उपयोग करके सेल डेटा संग्रहीत करने के लिए।

EAV

सरणी

दोनों स्कीमाओं में उपयुक्त स्तंभों पर अनुक्रमित हैं, और सूचकांक द्वारा उपयोग किया जाता है।

यह पता चला कि सरणी-आधारित स्कीमा आवेषण और प्रश्नों दोनों के लिए तेजी से परिमाण का क्रम था । त्वरित परीक्षणों से, ऐसा लग रहा था कि दोनों रैखिक रूप से बढ़े हैं। परीक्षण बहुत गहन नहीं हैं, हालांकि। सुझाव और कांटे का स्वागत - वे एक एमआईटी लाइसेंस के तहत हैं।

Comments

आपने सरणी मॉडल के साथ शीट कॉलम (अर्थात विस्पअप) पर कैसे शामिल किया? क्या आपको अपना सरणी मर्ज-सॉर्ट फ़ंक्शन नहीं लिखना है? अत्यधिक संदेह है कि यह precompiled मर्ज सॉर्ट के रूप में अच्छा हो सकता है यदि आपने सेल वैल्यू की कुंजी के रूप में एक सेल के sheet_id + x-समन्वय + y-समन्वय का उपयोग किया है। (एक्सेल का अनुकरण करने के लिए, x-निर्देशांक के लिए एक लुकअप टेबल को प्रीगेंरेट करें जहां 0-18278 कॉलम A-ZZZ हैं (16384 पर एक्सेल अधिकतम)), फिर आप उन मानों का चयन कर सकते हैं जहां sheet_id = uuid और x-ord = 0 और y-coord <1001 कॉल ए की पहली 1000 पंक्तियों को प्राप्त करने के लिए

— काउबर्ड जूल

@ जेंकबर्ट आप सही कह रहे हैं; वास्तव में मैं सिर्फ उन कॉलमों को लोड करता हूं जिनकी मुझे दिलचस्पी है और पायथन में शामिल हों। निर्बल!

— zrr