साझा डेटा के साथ Mongodb डेटाबेस स्कीमा डिज़ाइन

आपकी चुनौती इस तथ्य से आती है कि Prop_Info दोनों प्रश्नों द्वारा पुनर्प्राप्त किया जाना चाहिए। इससे यह पता लगाना मुश्किल हो जाता है कि उसे किस मोंगो संग्रह में रहना चाहिए।

MongoDB में, आप एक दस्तावेज़ के लिए आदर्श लक्ष्य के साथ अपना दस्तावेज़ स्कीमा बनाते हैं, जिसमें आपके क्वेरी पैटर्न के लिए आवश्यक सभी जानकारी होती है। उस मामले में जहां आपको समान डेटा की आवश्यकता होती है D (जैसे Prop_Info आपके मामले में) दो अलग-अलग संग्रहों के खिलाफ दो अलग-अलग प्रश्नों द्वारा लौटाए गए A और बी , आपको निम्नलिखित तीन रणनीतियों के बीच चयन करना होगा:

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

2. डी लगाएं ए . में और B . में एक संदर्भ (DBRef या पहचानने वाले क्षेत्रों का कोई अन्य संयोजन) संग्रहीत करें ताकि आप इसे दूसरी क्वेरी के साथ प्राप्त कर सकें। यह आमतौर पर डिज़ाइन विकल्प होता है जब प्रश्नों की संख्या A . होती है क्वेरी की संख्या B . से अधिक है . यह D . रखता है अधिक बार पूछे जाने वाले संग्रह के लिए स्थानीय। इस स्कीमा डिज़ाइन पैटर्न में आपको केवल दूसरी क्वेरी करने की आवश्यकता होती है जब आप B query को क्वेरी करते हैं ।

3. डी लगाएं एक नए संग्रह में C और इसके लिए A . दोनों से दूसरी क्वेरी करें और बी . यह आम तौर पर बहुत अनिश्चित भविष्य की आवश्यकताओं के सामने डिजाइन विकल्प है जहां यह स्पष्ट नहीं है कि यदि आप ऊपर (1) या (2) के साथ जाते हैं तो ट्रेड-ऑफ क्या होगा। यह सबसे "रिलेशनल-लाइक" स्कीमा है और जब आप A दोनों को क्वेरी करते हैं तो आपको दूसरी क्वेरी करने के लिए मजबूर करेगा। और बी .

आप कौन सी रणनीति चुनते हैं यह आपके डोमेन, क्वेरी पैटर्न, आपके ऑब्जेक्ट-रिलेशनल मैपिंग (ओआरएम) ढांचे (यदि आप एक का उपयोग करते हैं) से प्राप्त समर्थन पर निर्भर करता है, और आखिरी लेकिन कम से कम, आपकी वरीयता पर निर्भर करता है।

जिन स्थितियों का मैंने सामना किया है, मैंने कभी नहीं चुना है (3)। मैंने उच्च-प्रदर्शन स्थितियों (एनालिटिक्स सिस्टम) में (1) का उपयोग किया है। मैंने हर जगह (2) का उपयोग किया है क्योंकि क्वेरी एक्सेस पैटर्न ने यह स्पष्ट कर दिया है कि "साझा" डेटा कहाँ रहना चाहिए।

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

तीन अंतिम टिप्स:

1. यदि साझा किया गया डेटा D . है 1 से अधिक संबंध बहुलता है एक सरणी का उपयोग करें। आप संपूर्ण सरणियों को अनुक्रमित कर सकते हैं और आप <का उपयोग करके सरणी के अंदर सटीक रूप से क्वेरी कर सकते हैं कोड>$elemMatch ।

2. अपडेट करने के लिए डी रणनीति में (1) या (2) MongoDB के परमाणु संशोधक का उपयोग करें संचालन , जिनमें से कई को सरणियों पर संचालित करने के लिए डिज़ाइन किया गया है।

3. यह SO प्रश्न @ स्टेनी के उत्तर में DBRef दो क्वेरी पैटर्न को शामिल करता है। (@Stennie MongoDB के मार्कर 10gen के लिए काम करता है।)

आपको कामयाबी मिले!