2012-12-26 13 views
7

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

आइए यह भी मान लें कि अधिकांश खोज/प्रश्न कर्मचारियों और कंपनियों के संग्रह पर किए जाएंगे।

पहले (भोली) तरीका यह है सब कुछ एम्बेड करने के लिए (कंपनी शाखाओं की सरणी है और शाखाओं के कर्मचारियों की सरणी है) होगा:

{ 
    name: "Company name", 
    // other company data 
    branches : [ 
     { 
      name: "Branch name", 
      // other branch data 
      Employees: [ 
       { 
        // employee1 data 
       }, 
       { 
        // employee data 
       }, 
      ] 
     } 
    ] 
} 

लेकिन यह बहुत अक्षम होगा जब एक में रुचि होगी कर्मचारी जानकारी पुनर्प्राप्त करना (किसी को कंपनी को पुनर्प्राप्त करना होगा और फिर आवश्यकतानुसार कर्मचारी ढूंढने के लिए प्रत्येक शाखा में फिर से भरना होगा)।

दूसरी तरफ, कोई संदर्भों का उपयोग कर सकता है और आरडीबीएमएस की नकल कर सकता है (कंपनी, शाखा और कर्मचारी संग्रह होगा), लेकिन इसका मतलब अधिक प्रश्न होगा।

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

{ 
    company_id: "some id", 
    first_name: "First name", 
    last_name: "Last name", 
    // 
} 

तो, इस मामले में, सभी के लिए खोज करने के लिए इसके अलावा, की तरह तेजी से प्रश्नों अनुमति देने के लिए कुछ नाम वाले कर्मचारी जो कुछ कंपनी और कुछ शाखा के लिए काम करते हैं, उन्हें दो प्रश्न करना होगा। पहली क्वेरी उन कंपनियों को वापस लाएगी जो "कंपनी की स्थिति" (कंपनी का नाम और शाखा का नाम) को संतुष्ट करती हैं और फिर कर्मचारी संग्रह पर दूसरी क्वेरी उन सभी कर्मचारियों को वापस कर देगी जिनके पास निर्दिष्ट नाम है और जो उन कंपनियों में काम कर रहे हैं जिनकी आईडी पहली क्वेरी में लौटा दी गई है।

क्या आप इसे किसी अन्य तरीके से करेंगे? क्या ऐसा करने के लिए कुछ और "अनुशंसित" तरीका है? क्या आप कुछ सुधार जोड़ देंगे?

अधिक महत्वपूर्ण बात यह है कि स्थिति में क्या करना है जब इन दो प्रश्नों के परिणाम परिणाम छोटे छेड़छाड़ करते हैं? उस मामले में प्रदर्शन में सुधार कैसे करें?

उत्तर

4

मुझे लगता है कि आप अधिकतर सही दिशा में आगे बढ़ रहे हैं।

ऐसे मामले हैं जहां मोंगो डीबी में denormalization एक संबंधपरक डेटाबेस में बुरा नहीं है, लेकिन वास्तव में करने के लिए सही बात है, आप यहां एक मामला है जहां आप एकाधिक संग्रह का उपयोग करना चाहिए। ऐसा इसलिए है क्योंकि मोंगोडीबी दस्तावेजों की ऊपरी सीमा 16 एमबी है। जब आपके पास बहुत सारी शाखाएं होती हैं जिनमें बहुत से कर्मचारी होते हैं, और कर्मचारी उप-दस्तावेज़ अधिक गड़बड़ हो जाते हैं, तो आप आसानी से उस सीमा को क्रैक कर सकते हैं।

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

आपने कहा कि आपके पास शाखाओं और कर्मचारियों के बीच 1: एन संबंध नहीं है, बल्कि एक एन: एम संबंध है।उस स्थिति में मैं आपको प्रत्येक कर्मचारी को "असाइनमेंट" की एक सरणी जोड़ने की सलाह दूंगा, जिसमें दो फ़ील्ड्स, कंपनी_नाम और कंपनी_ब्रैंच के साथ ऑब्जेक्ट शामिल हैं (शायद आप एक तीसरा क्षेत्र "स्थिति" जोड़ना चाहते हैं जो कहता है कि वह क्या कर रहा है क्या आप वहां मौजूद हैं)।

आपका कर्मचारी दस्तावेजों तो वह दिखाई देगा:

{ 
    first_name: "First name", 
    last_name: "Last name", 
    // 
    assignments: [ 
     { company:"Aperture Science", branch:"R&D", position:"test subject" }, 
     { company:"Black Mesa", branch:"security", position:"leader of blue shift" } 
    ] 
} 

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

लेकिन जब मैं किसी कंपनी या शाखा का नाम बदलना चाहता हूं?

उस स्थिति में आपको प्रत्येक कर्मचारी दस्तावेज़ को अपडेट करना होगा जो नामित कंपनी/शाखा का संदर्भ देता है। हां, यह उस मामले के लिए सबसे कुशल स्कीमा नहीं होगा। लेकिन याद रखें कि मोंगोडीबी स्कीमा को हमेशा सबसे आम उपयोग-मामलों के लिए अनुकूलित किया जाना चाहिए। आपको क्या लगता है कि अधिक बार होगा: ए) एक कंपनी या शाखा का नाम बदल दिया गया है या बी) कोई कर्मचारी देखना चाहता है?

+0

प्रतिक्रिया के लिए धन्यवाद। समस्या, उदाहरण के लिए कंपनी, शाखा और कर्मचारी सिर्फ एक उदाहरण थे। मुझे असाइनमेंट सरणी के साथ कई से अधिक रिश्तों का सिमुलेशन पसंद है। मैं इसका उपयोग करूंगा और वहां सभी "खोजने योग्य" फ़ील्ड जोड़ दूंगा। मैं 16 एमबी सीमा नहीं मारूंगा, लेकिन मैं कई संग्रहों के साथ जाने की सोच रहा था - एक कंपनी के लिए (शाखा इसमें एम्बेडेड होगी), और एक कर्मचारी के लिए। – kevin

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