आपको उन प्रश्नों के प्रकार पर विचार करने की आवश्यकता है जिन्हें आपको निष्पादित करने की आवश्यकता होगी और प्रत्येक प्रकार की कितनी बार आवश्यकता होगी। जब मैं कुछ इसी तरह पर काम कर रहा था, तो मैं छह संभावित कार्रवाइयों के साथ आया:
- माता-पिता के साथ कुछ करें
- बच्चों के साथ कुछ करें
- पूर्वजों (माता-पिता के माता-पिता, माता-पिता के माता-पिता आदि) के साथ कुछ करें
- वंशजों के साथ कुछ करो (बच्चों के बच्चे, बच्चों के बच्चों के बच्चे, आदि)
- संबंध बदलें (पदानुक्रम में नोड्स जोड़ें/स्थानांतरित/हटाएं)
- वर्तमान नोड में मुख्य डेटा बदलें (उदा. "शीर्षक" फ़ील्ड में मान बदलना)
आप अनुमान लगाना चाहेंगे कि इनमें से प्रत्येक आपके आवेदन के लिए कितना महत्वपूर्ण है।
यदि आपके अधिकांश काम में किसी दिए गए लेख के लिए उसके तत्काल माता-पिता और बच्चों सहित संग्रहीत डेटा के साथ काम करना शामिल है, तो पहला विचार सर्वाधिक उपयोगी है। वास्तव में मोंगोडीबी में, बाहरी रूप से संदर्भित करने के बजाय आपको एक ही दस्तावेज़ में आवश्यक सभी जानकारी रखना काफी आम है ताकि आपको केवल एक चीज़ पुनर्प्राप्त करने की आवश्यकता हो और केवल उस डेटा के साथ काम करना पड़े। हालांकि सूची में अंतिम चार क्रियाएं अधिक कठिन हैं।
विशेष रूप से, आपको इस मामले में पूर्वजों और वंशजों को पुनः प्राप्त करने के लिए पेड़ के माध्यम से पार करने की आवश्यकता होगी, मध्यस्थ दस्तावेजों के माध्यम से आगे बढ़ना और पथ का पालन करना, भले ही आप पथ में केवल अंतिम दस्तावेज़ की परवाह कर सकें। यह लंबे पदानुक्रमों के लिए धीमा हो सकता है। रिश्तों को बदलने के लिए हर एक में मौजूद सभी डेटा के कारण कई दस्तावेज़ों में बहुत सारी जानकारी को इधर-उधर करने की आवश्यकता हो सकती है। लेकिन यहां तक कि "शीर्षक" जैसे एकल फ़ील्ड को बदलना कष्टप्रद हो सकता है, क्योंकि आपको इस तथ्य पर विचार करना होगा कि यह फ़ील्ड कई अलग-अलग दस्तावेज़ों में मौजूद है, या तो मुख्य फ़ील्ड के रूप में या माता-पिता या बच्चों के फ़ील्ड के तहत।
मूल रूप से, आपका पहला विचार अधिक स्थिर अनुप्रयोगों . में सर्वोत्तम कार्य करता है जहां आप शुरू में इसे बनाने के बाद डेटा को बहुत अधिक नहीं बदलेंगे, लेकिन जहां आपको इसे नियमित रूप से पढ़ने की आवश्यकता होगी।
MongoDB दस्तावेज़ में पांच अनुशंसित दृष्टिकोण हैं। पेड़ जैसी (पदानुक्रमित) संरचनाओं को संभालने के लिए। उन सभी के अलग-अलग फायदे और नुकसान हैं, हालांकि वे सभी एक लेख में मुख्य डेटा को अपडेट करना आसान बनाते हैं, केवल एक दस्तावेज़ में ऐसा करने की आवश्यकता होती है।
- अभिभावक संदर्भ :प्रत्येक नोड में उसके माता-पिता का संदर्भ होता है।
- फायदे :
- फास्ट पैरेंट लुकअप ("_id" द्वारा लुकअप =आपका डॉक्टर शीर्षक, "पैरेंट" फ़ील्ड लौटाएं)
- फास्ट चिल्ड्रन लुकअप ("पैरेंट" द्वारा लुकअप =आपका डॉक्टर शीर्षक, जो सभी चाइल्ड डॉक्यूमेंट लौटाएगा)
- संबंधों को अपडेट करना केवल "पैरेंट" फ़ील्ड को बदलने की बात है
- अंतर्निहित डेटा को बदलने के लिए केवल एक दस्तावेज़ में परिवर्तन की आवश्यकता है
- नुकसान :
- पूर्वजों और वंशजों द्वारा खोजना धीमा है, एक ट्रैवर्सल की आवश्यकता है
- बाल संदर्भ :प्रत्येक नोड में अपने बच्चों के लिए एक संदर्भ सरणी होती है
- फायदे :
- बच्चों की तेजी से पुनर्प्राप्ति (बच्चों की सरणी लौटाएं)
- तेज़ संबंध अपडेट (जहाँ आवश्यक हो, बस बच्चों के एरे को अपडेट करें)
- नुकसान :
- माता-पिता को ढूंढने के लिए सभी दस्तावेज़ों के सभी बच्चों के सरणियों में अपना _id देखने की आवश्यकता है जब तक कि आप इसे नहीं ढूंढ लेते (क्योंकि माता-पिता में बच्चे के रूप में वर्तमान नोड होगा)
- पूर्वजों और वंशजों की खोज के लिए पेड़ के ट्रैवर्सल की आवश्यकता होती है
- फायदे :
- पूर्वजों का समूह :प्रत्येक नोड में अपने पूर्वजों और उसके माता-पिता की एक सरणी का संदर्भ होता है
- फायदे :
- पूर्वजों की तेजी से पुनर्प्राप्ति (किसी विशिष्ट को खोजने के लिए किसी ट्रैवर्सल की आवश्यकता नहीं है)
- "अभिभावक संदर्भ" दृष्टिकोण के बाद माता-पिता और बच्चों को देखने में आसान
- वंशजों को खोजने के लिए, केवल पूर्वजों को देखें, क्योंकि सभी वंशजों के पूर्वज एक जैसे होने चाहिए
- नुकसान :
- जब भी रिश्तों में बदलाव होता है, अक्सर कई दस्तावेज़ों में पूर्वजों की सरणी के साथ-साथ मूल फ़ील्ड को अद्यतन रखने के बारे में चिंता करने की आवश्यकता होती है।
- फायदे :
- भौतिक पथ :प्रत्येक नोड में स्वयं के लिए एक पथ होता है - इसके लिए रेगेक्स की आवश्यकता होती है
- फायदे :
- रेगेक्स का उपयोग करके बच्चों और वंशजों को ढूंढना आसान
- माता-पिता और पूर्वजों को पुनः प्राप्त करने के लिए पथ का उपयोग कर सकते हैं
- लचीलापन, जैसे आंशिक पथों से नोड्स ढूंढना
- नुकसान :
- रिश्ते में बदलाव मुश्किल है क्योंकि उन्हें कई दस्तावेज़ों में पथ में बदलाव की आवश्यकता हो सकती है
- फायदे :
- नेस्टेड सेट :प्रत्येक नोड में उप-पेड़ों को खोजने में सहायता के लिए "बाएं" और "दाएं" फ़ील्ड होते हैं
- फायदे :
- "बाएं" और "दाएं" के बीच खोज कर एक इष्टतम तरीके से वंशजों को पुनः प्राप्त करना आसान है
- "अभिभावक संदर्भ" दृष्टिकोण की तरह, माता-पिता और बच्चों को ढूंढना आसान है
- नुकसान :
- पूर्वजों को खोजने के लिए संरचना को पार करने की आवश्यकता है
- संबंध परिवर्तन किसी भी अन्य विकल्प की तुलना में यहां सबसे खराब प्रदर्शन करते हैं क्योंकि पेड़ में हर एक दस्तावेज़ को बदलने की आवश्यकता हो सकती है ताकि यह सुनिश्चित हो सके कि "बाएं" और "दाएं" अभी भी एक बार पदानुक्रम में कुछ बदलाव के बाद समझ में आता है
- फायदे :
पांच दृष्टिकोणों पर MongoDB दस्तावेज़ीकरण में अधिक विस्तार से चर्चा की गई है। ।
आपका दूसरा विचार ऊपर चर्चा की गई "अभिभावक संदर्भ" और "बाल संदर्भ" दृष्टिकोणों को जोड़ती है। यह दृष्टिकोण बच्चों और माता-पिता दोनों को ढूंढना आसान बनाता है और रिश्तों और लेख के मुख्य डेटा को अपडेट करना आसान बनाता है (हालांकि आपको माता-पिता और बच्चों दोनों क्षेत्रों को अपडेट करने की आवश्यकता है), लेकिन आपको अभी भी इसके माध्यम से पार करने की आवश्यकता है पूर्वजों और वंशजों को खोजने के लिए।
यदि आप पूर्वजों और वंशजों को खोजने में रुचि रखते हैं (और रिश्तों को आसानी से अपडेट करने में सक्षम होने से अधिक इसकी परवाह करते हैं), तो आप पूर्वजों और वंशजों के लिए क्वेरी करना आसान बनाने के लिए अपने दूसरे विचार में पूर्वजों की सरणी जोड़ने पर विचार कर सकते हैं। बेशक, अगर आप ऐसा करते हैं तो रिश्तों को अपडेट करना एक वास्तविक दर्द बन जाता है।
निष्कर्ष:
-
अंततः यह सब इस बात पर निर्भर करता है कि किन कार्यों की सबसे अधिक आवश्यकता है। चूंकि आप उन लेखों के साथ काम कर रहे हैं, जिनका अंतर्निहित डेटा (जैसे शीर्षक) बार-बार बदल सकता है, आप पहले विचार से बचना चाह सकते हैं क्योंकि आपको उस लेख के लिए न केवल मुख्य दस्तावेज़ बल्कि सभी चाइल्ड दस्तावेज़ों को भी अपडेट करने की आवश्यकता होगी। माता पिता
-
आपका दूसरा विचार तत्काल माता-पिता और बच्चों को पुनः प्राप्त करना आसान बनाता है। संबंधों को अद्यतन करना भी बहुत कठिन नहीं है (यह निश्चित रूप से उपलब्ध कुछ अन्य विकल्पों से बेहतर है)।
-
यदि आप वास्तव में रिश्तों को आसानी से अद्यतन करने की कीमत पर पूर्वजों और वंशजों को ढूंढना आसान बनाना चाहते हैं, तो पूर्वजों के संदर्भों की एक सरणी शामिल करना चुनें।
-
सामान्य तौर पर, आवश्यक ट्रैवर्सल की संख्या को कम करने का प्रयास करें, क्योंकि उन्हें अपने इच्छित डेटा को प्राप्त करने के लिए किसी प्रकार के पुनरावृत्ति या रिकर्सन को चलाने की आवश्यकता होती है। यदि आप रिश्तों को अद्यतन करने की क्षमता को महत्व देते हैं, तो आपको एक विकल्प भी चुनना चाहिए जो पेड़ में कम नोड्स बदलता है (अभिभावक संदर्भ, बाल संदर्भ, और आपका दूसरा विचार ऐसा कर सकता है)।
