2011-12-19 14 views
5

मैं अपने आरडीबीएमएस मानसिकता को मोंगोस के साथ एक नोड.जेएस ऐप में तोड़ने की कोशिश कर रहा हूं, और कुछ अभ्यासों को सर्वोत्तम प्रथाओं के रूप में उपयोग कर सकता हूं।मोंगोस स्कीमा/क्वेरी सर्वोत्तम प्रथाओं (मोंगोडीबी, नोड.जेएस)

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

ऐसा लगता है कि मैं इसे पूरा करने का सबसे अच्छा तरीका गलत समझ रहा हूं। यहां विकल्प हैं जिन्हें मैं अब तक देखता हूं:

  1. संगठन दस्तावेज़ों में उनके आईडी के साथ संपर्क एम्बेड करें। सूचकांक क्वेरी Organization.find({}, function(err, orgs) { orgs[n].contacts[n]...}) हो सकती है। नुकसान: अतिरिक्त संग्रहण आवश्यक है, और जब भी आप "मास्टर" संपर्क दस्तावेज़ बदलते हैं तो एम्बेडेड संपर्क दस्तावेज़ अपडेट करना होगा।

  2. दोनों टेबलों में "विदेशी कुंजी" आईडी स्टोर करने के लिए मोंगोस के populate/DBRef संरचना का लाभ उठाएं। क्वेरी तब हो सकती है: Organization.find({}}.populate('contacts').run(...)नुकसान: आपको दोनों तरफ कुंजी स्टोर करना होगा।

  3. अधिक पारंपरिक "विदेशी कुंजी" मार्ग पर जाएं, केवल एक संपर्क दस्तावेज़ में संगठन आईडी संग्रहीत करें। संगठन दस्तावेजों की क्वेरी करें और फिर संगठन क्वेरी के कॉलबैक में सभी संपर्कों से पूछें, डेटा को एक ऑब्जेक्ट में वापस करने के लिए संयोजन करें। नुकसान: एकाधिक प्रश्न और अतिरिक्त प्रसंस्करण ओवरहेड (मुझे विश्वास है कि हमें स्वतंत्र रूप से उन orgs के लिए orgs और संपर्क ढूंढना होगा और फिर सामान्य _id फ़ील्ड पर मैन्युअल रूप से मिलान करने के लिए प्रत्येक को फिर से चालू करना होगा, ताकि उन्हें एक नई आउटपुट ऑब्जेक्ट में गठबंधन किया जा सके) ।

मुझे एक बेहतर विकल्प याद आना चाहिए। कुछ जो # 3 की स्कीमा की अनुमति देता है लेकिन वांछित संयुक्त वस्तु को बहुत कम ओवरहेड के साथ देता है।

नोट: async मॉड्यूल यह की तरह लगता है इस के साथ मदद कर सकता है, लेकिन यह वास्तव में केवल/सबसे अच्छा तरीका है?

उत्तर

2

यह वास्तव में उन प्रश्नों पर निर्भर करता है जिन्हें आप बनाना चाहते हैं। - क्या आपकी साइट संपर्कों या संगठनों पर अधिक निर्भर करती है? - क्या आपको अक्सर किसी संगठन से सभी संपर्क प्रदर्शित करने की आवश्यकता होगी? - किसी संगठन पृष्ठ पर आपको संपर्कों के लिए किन विवरणों की आवश्यकता है?

आदि

तो यह वास्तव में आपके प्रोजेक्ट की ज़रूरतों पर निर्भर करता है। क्या आप संगठनों और संपर्क पृष्ठ को लगातार अद्यतन कर रहे हैं? यदि डेटा डुप्लिकेट करने से नहीं है तो ऐसा बुरा विचार नहीं लगता है, खासकर यदि आपकी साइट अधिक पढ़ी जाती है।

नीचे पंक्ति: इस साइट पर आपके पास कौन से पेज होंगे और इस पृष्ठ को प्रदर्शित करने की आवश्यकता होगी (इस प्रकार कौन से प्रश्नों को बनाने की आवश्यकता होगी) पर विचार करें।

+0

आपकी प्रतिक्रिया के लिए धन्यवाद। ऐप दोनों संपर्कों और संगठनों पर समान रूप से निर्भर करता है। यही है, कुछ उपयोगकर्ता ऑरग्स के लिए अधिक तीव्रता से उन्मुख हैं, कुछ संपर्कों में हैं।सभी मामलों में, प्रत्येक संगठन के लिए सभी संपर्कों को दिखाने की आवश्यकता होगी। कुल मिलाकर, लिखने की तुलना में अधिक पढ़ने की आवश्यकता होगी, लेकिन अगर हम सभी संगठन दस्तावेजों में संपर्क डेटा एम्बेड करना चाहते हैं तो भंडारण स्थान अंततः चिंता का विषय होगा। अभी के लिए, मुझे लगता है कि यह # 2 के साथ रहना अधिक समझ सकता है क्योंकि यह दूसरों की देनदारियों को कम करता है। लेकिन दोनों तरफ से आईडी स्टोर करने के लिए अभी भी बेतुका लगता है! – glortho

+0

यह बुरा नहीं है, आप केवल 2 प्रश्न बना रहे हैं (संग्रह के लिए एक और दूसरा संदर्भित डेटा के लिए)। इस समय आपके लिए यह सबसे सुरक्षित समाधान है, तो यदि आप चाहें तो भविष्य में संरचना बदल सकते हैं। – alessioalex

संबंधित मुद्दे