क्या मुझे ईएवी मॉडल का उपयोग करना चाहिए?

Question

मैं एक ई-कॉमर्स एप्लिकेशन के लिए अपना डेटाबेस/डोमेन डिज़ाइन कर रहा हूं और मुझे उत्पादों को स्टोर करने के तरीके को समझने में कठिनाई हो रही है।

वेबसाइट उत्पाद, पेन, पेटी, टैटू, छतरियों, सब कुछ की एक विस्तृत श्रृंखला बेच देगा। इनमें से प्रत्येक उत्पाद कुछ सामान्य विशेषताओं, ऊंचाई, चौड़ाई, लंबाई, वजन, आदि साझा करेगा लेकिन कुछ उत्पादों में विशेष डेटा होगा। उदाहरण के लिए, पेन में विभिन्न स्याही रंग होते हैं और टिप्स/ढक्कन और ब्रोशर में विभिन्न प्रकार के फोल्ड हो सकते हैं। अब तक मैंने कुछ 20+ अतिरिक्त विशेषताओं को सोचा है, लेकिन ये विशेषताएं केवल वेबसाइट पर उत्पादों के 1% पर लागू हो सकती हैं।

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

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

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

विकल्पों में से समीक्षा करें:

1. कॉलम के बहुत सारे के साथ एकल उत्पादों इकाई
2. अलग विशेषताओं इकाई (EAV)
3. स्विच करने के लिए स्कीमा-कम हठ

मैं तैयार हूं एक विशेषता इकाई के साथ एक प्रोटोटाइप बनाने की प्रक्रिया यह देखने के लिए कि यह कितना लचीला है, और प्रदर्शन का परीक्षण और पूछताछ को नियंत्रित करने के तरीके से बाहर कैसे होता है।

संपादित करें: मैं निश्चित रूप से, किसी अन्य समाधान के लिए खुला हूं।

Answer 1

महान प्रश्न, लेकिन निश्चित रूप से, कोई "एक सही तरीका" नहीं है। @ बीएनवी के अनुसार, Magento ईएवी मॉडल का उपयोग करता है। इसके साथ मेरा अनुभव भारी सकारात्मक रहा है, हालांकि यह अन्य उपयोगकर्ताओं की यात्रा करता है। कुछ विचार:

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

2. 3 पार्टी उपयोगकर्ता जटिलता आप कभी भी इस आवेदन अन्य उपयोगकर्ताओं के लिए उपलब्ध बनाने के लिए योजना है, कई EAV बहुत जटिल मिलेगा और आप उपयोगकर्ता पर मिमिया का एक बहुत और बेख़बर दुरुपयोग पर कार्रवाई पहुंच जाएंगे मंच (रेफ Magento !!)।

3. भविष्य विस्तार और प्लगइन वास्तुकला। इसमें कोई संदेह नहीं है कि ईएवी मॉडल वास्तव में अपने आप में आता है जब एक्स्टेंसिबिलिटी एक कारक है। मौजूदा ओआरएम और नियंत्रक कोड को तोड़ने के जोखिम को कम करते हुए मॉडल में नए विशेषताओं को जोड़ना बहुत आसान है।

4. परिवर्तन डेटाप्रकार में EAV यह थोड़ा कठिन विशेषता डेटाटाइप्स बदलने में सहायता की है। यदि आपका प्रारंभिक डिज़ाइन किसी विशेष विशेषता डेटाटाइप के लिए कॉल करता है जो भविष्य में बदलता है (int से varchar पर) कहें, तो इसका मतलब है कि आपको उस विशेषता के लिए सभी रिकॉर्ड्स को नए डेटाटाइप से मेल खाने वाली संबंधित तालिका में माइग्रेट करना होगा। बेशक, शुद्धवादियों का सुझाव है कि आपको पहली बार डिजाइन मिल जाए, लेकिन वास्तविकता कभी-कभी घुसपैठ करती है!

5. मैनुअल उत्पाद आयात एक बात है कि EAV लगभग असंभव बना देता है एसक्यूएल और/या phpMyAdmin शैली CSV/XML का उपयोग कर डेटाबेस में उत्पादों (या अन्य संस्थाओं) आयात कर रहा है। आपको एक आयातक मॉड्यूल लिखना होगा जो संरचित डेटा स्वीकार करता है और इसे डेटाबेस के लिए जारी रखने के लिए एप्लिकेशन की मॉडल परत के माध्यम से गुजरता है। यह आपकी जटिलता में जोड़ता है।

Answer 2

ओपन सोर्स शॉपिंग कार्ट Magento ईएवी डिज़ाइन का उपयोग करके अपने उत्पादों के लिए कस्टम विशेषताओं की अनुमति देता है। आप उनकी डेटाबेस स्कीमा here देख सकते हैं।

Answer 3

मैं आपको इसके लिए ओएक्सएम प्लगइन के साथ सिद्धांत 2 ओआरएम पर देखने के लिए सुझाव दूंगा (https://github.com/doctrine/oxm)। यह आपकी विशेषताओं के साथ आपकी समस्या का समाधान करेगा। बेशक आपको खोजने योग्य कस्टम विशेषताओं के लिए इंडेक्स बनाने की आवश्यकता होगी, लेकिन मुझे नहीं लगता कि यह एक समस्या होगी :)

यदि आपको समुदाय के सदस्यों की संख्या की परवाह नहीं है, तो आप मोंगोडीबी का भी उपयोग कर सकते हैं ।