गतिशील टैक्सोनोमी से निपटने के लिए समर्पित पहलू खोज इंजन - प्रदर्शन या flexibilty के साथ मदद करता है?

Question

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

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

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

• ऑल्टर/तालिका विशिष्ट द्वारा भीतर इस तरह के वर्ग छानने के लिए
• नए रूप बनाने, खोज और फ़िल्टर
• कुछ नए ViewModels के लिए डाटाबेस प्रश्नों पैदा करने के लिए
• नए कोड का श्रेय/डीटीओ और नई श्रेणियों से उत्पादों को प्रस्तुत करने के विचार

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

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

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

1) मैं आरडीबीएमएस में डेटा EAV fasion का उपयोग कर SOLR खोज का उपयोग कर के साथ EAV messiness, कोई डेटा के साथ रहेगा और पर काबू पाने के अपने प्रदर्शन की समस्याओं (लेकिन अभी भी होगा समस्याओं अखंडता प्रवर्तन आदि)

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

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

वहाँ प्रश्न के बहुत यहाँ है, लेकिन मैं इसे तोड़ने के लिए छोटे प्रश्नों में नहीं करना चाहता था क्योंकि मैं एक सामान्य डिजाइन दृष्टिकोण में दिलचस्पी रखता हूँ जब इस तरह की समस्याओं का एक बड़ा वर्ग के साथ काम कर।

Answer 1

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

1. मैं इसे आरडीबीएमएस पर मॉडलिंग के बारे में भूल जाऊंगा। Faceted search just doesn't work in a relational schema।
2. आईएमओ यह कोड पीढ़ी के लिए सही जगह नहीं है। आपको अपना कोड डिज़ाइन करना चाहिए ताकि डेटा परिवर्तनों में बदलाव न हो (मैं स्कीमा परिवर्तनों के बारे में बात नहीं कर रहा हूं)।
3. एक्सेल स्प्रेडशीट पर मेटाडेटा/विशेषताओं को संग्रहीत करना बहुत बुरा विचार है। मैं इसे संपादित करने के लिए एक यूआई बनाना चाहता हूं, जिसे सोलर/मोंगोडीबी/कॉच डीबी/जो भी आप इसे प्रबंधित करने के लिए चुनते हैं, पर संग्रहीत किया जाएगा।
4. सोलर "सिर्फ मिरर रिलेशनल डीबी" नहीं है। वास्तव में, सोलर संबंधपरक डेटाबेस से पूरी तरह से स्वतंत्र है। सबसे आम मामलों में से एक एक आरडीबीएमएस से सोलर (प्रक्रिया में डेटा को denormalizing) से डेटा डंपिंग है, लेकिन सोलर किसी भी संबंधपरक डेटा स्रोत के बिना काम करने के लिए पर्याप्त लचीला है।
5. Hierarchical faceting in Solr अभी भी अनुसंधान में एक खुला मुद्दा है। दो अलग-अलग दृष्टिकोण शोध किया जा रहा वर्तमान में कर रहे हैं (SOLR-64, SOLR-792)

Answer 2

क्या होगा यदि आप उत्पादों के विभिन्न प्रकार के लिए श्रेणियों के विभिन्न प्रकार था?

eBay उदाहरण लें तो हम उत्पाद है कि या तो पुस्तकें या टी वी/प्रदर्शित करता है हो सकता है के लिए होगा।

पुस्तकें शीर्षक और आईएसबीएन हैं, और विज्ञान-फाई श्रेणी में, या कामुक श्रेणी में, या गैर-कथा श्रेणी या आत्मकथात्मक श्रेणी में हो सकती हैं। या शायद आपके पास ऐसी पुस्तक है जो गैर-कथा, आत्मकथात्मक कामुक श्रेणियों में है।

प्रदर्शित स्क्रीन रिज़ॉल्यूशन और वाट-खपत (?) है, और फ्लैट स्क्रीन श्रेणी, सीआरटी श्रेणी, या एचडी श्रेणी में हो सकता है।

देखने के एक विशुद्ध रूप से संबंधपरक बिंदु से, आप शायद सकता मॉडल यह इतना की तरह: मॉडलिंग attributes dependent on a particular product category के बजाय

[Product]-(1)------(1)-[ Book ]-(n)------(m)-[ book_category ] 
| id |    | title |    | name   | 
| price |    | ISBN | 
| ... | 
| ... |-(1)---(1)-[ display ]-(n)------(m)-[ display_category ] 
        | resolution |    | name   | 
        | watts | 

, आप विभिन्न गुणों और श्रेणियोंप्रकार/वर्ग पर निर्भर होता है उत्पाद के।

देखें supertypes & subtypes