स्प्रिंग डेटा मोंगो - एम्बेडेड दस्तावेज़ में अद्वितीय संयोजन फ़ील्ड लागू करें

MongoDB में, एक अद्वितीय अनुक्रमणिका यह सुनिश्चित करती है कि किसी फ़ील्ड में एक विशेष मान एक से अधिक दस्तावेज़ों में मौजूद नहीं है। यह नहीं होगा गारंटी दें कि एक मान एक दस्तावेज़ के भीतर एक सरणी में अद्वितीय है। इसे यहाँ MongoDB मैनुअल में समझाया गया है जहाँ यह अद्वितीय बहु-कुंजी अनुक्रमणिका पर चर्चा करता है।

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

आपके पास सबसे अच्छा विकल्प है कि आप अपने डेटा मॉडल को बदल दें ताकि TechnologyEmployeeRef ऑब्जेक्ट्स की सरणी को अलग-अलग दस्तावेज़ों में विभाजित किया जा सके। इसे अलग-अलग दस्तावेज़ों में विभाजित करने से आप विशिष्टता को लागू करने के लिए एक अद्वितीय अनुक्रमणिका का उपयोग कर सकेंगे।

इस डेटा मॉडल परिवर्तन के लिए जो विशेष कार्यान्वयन किया जाना चाहिए, वह आपके एक्सेस पैटर्न (जो इस प्रश्न के दायरे से बाहर है) पर निर्भर करेगा।

ऐसा ही एक तरीका यह किया जा सकता है कि एक प्रौद्योगिकी कर्मचारी संग्रह तैयार किया जाए जिसमें वे सभी क्षेत्र हों जो वर्तमान में TechnologyEmployeeRef सरणी में मौजूद हैं। इसके अतिरिक्त, इस तकनीकी कर्मचारी संग्रह में एक फ़ील्ड होगा, जैसे कि ईमेल, जो आपको इसे कर्मचारी संग्रह में एक दस्तावेज़ के साथ संबद्ध करने की अनुमति देगा।

नमूना कर्मचारी दस्तावेज़

{
  ....
  ....
  "firstName" : "John",
  "lastName" : "Doe",
  "email" : "[email protected]",
  .....
  .....
  .....
}

नमूना कर्मचारी प्रौद्योगिकी दस्तावेज़

{
  "email" : "[email protected]",
  "technologyCd" : "Java",
  "technologyName" : "Java8",
  ....
  .....
  "status" : "A"
}

कर्मचारी प्रौद्योगिकी संग्रह में अनुक्रमणिका

{'email' : 1, 'technologyCd' : 1}, {unique: true}

इस दृष्टिकोण का नुकसान यह है कि आपको सभी डेटा प्राप्त करने के लिए दो संग्रहों से पढ़ना होगा। यदि आपको एक ही समय में दोनों संग्रहों से डेटा पुनर्प्राप्त करने की शायद ही कभी आवश्यकता हो तो यह कमी कोई बड़ी बात नहीं हो सकती है। यदि आपको सभी डेटा की आवश्यकता है, तो इसे इंडेक्स के उपयोग के माध्यम से बढ़ाया जा सकता है। इंडेक्स के साथ, इसे कवर किए गए प्रश्नों के उपयोग के माध्यम से आगे बढ़ाया जा सकता है।

एक अन्य विकल्प डेटा को असामान्य बनाना है। आप कर्मचारी डेटा को डुप्लिकेट करके ऐसा करेंगे जिसे आपको उसी समय प्रौद्योगिकी डेटा के रूप में एक्सेस करने की आवश्यकता है।

नमूना दस्तावेज़

[
  {
    ....
    "firstName" : "John",
    "lastName" : "Doe",
    "email" : "[email protected]",
    .....
    "technologyCd" : "Java",
    "technologyName" : "Java8",
    ....
    "status" : "A"
  },
  {
    ....
    "firstName" : "John",
    "lastName" : "Doe",
    "email" : "[email protected]",
    .....
    "technologyCd" : "Spring",
    "technologyName" : "Spring Boot2",
    ....
    "status" : "A"
  }
]

इस MongoDB ब्लॉग पोस्ट में, वे कहते हैं कि

आप इसे केवल उन क्षेत्रों के लिए करेंगे जो अक्सर पढ़े जाते हैं, अपडेट होने की तुलना में अधिक बार पढ़ते हैं, और जहां आपको मजबूत स्थिरता की आवश्यकता नहीं होती है, क्योंकि एक असामान्य मान को अपडेट करना धीमा, अधिक महंगा है, और परमाणु नहीं है।

या जैसा कि आपने पहले ही उल्लेख किया है, डेटा मॉडल को वैसे ही छोड़ना और एप्लिकेशन पक्ष पर विशिष्टता की जांच करना समझ में आता है। यह संभवतः आपको सबसे अच्छा पठन प्रदर्शन दे सकता है, लेकिन इसके कुछ नुकसान भी हैं। सबसे पहले, यह लेखन कार्यों को धीमा कर देगा क्योंकि डेटाबेस को अपडेट करने से पहले एप्लिकेशन को कुछ जांच चलाने की आवश्यकता होगी।

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

कौन सा दृष्टिकोण सबसे अधिक समझ में आता है यह काफी हद तक आपके एक्सेस पैटर्न और आवश्यकताओं पर निर्भर करता है। आशा है कि यह मदद करता है।