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