MongoDB स्कीमा डिज़ाइन

जब कुछ साल पहले MongoDB को पेश किया गया था, तो एक महत्वपूर्ण विशेषता "स्कीमालेस" होने की क्षमता थी - आपके दस्तावेज़ों के लिए इसका क्या अर्थ है?

MongoDB स्कीमा डिज़ाइन संग्रह में संग्रहीत दस्तावेज़ों पर किसी भी स्कीमा को लागू नहीं करता है। MongoDB अनिवार्य रूप से JSON दस्तावेज़ों को संग्रहीत करता है, और प्रत्येक दस्तावेज़ में कोई भी संरचना हो सकती है जो आप चाहते हैं। नीचे हमारे "संपर्क" संग्रह से कुछ उदाहरणों पर विचार करें। यहां एक दस्तावेज़ है जिसे आप स्टोर कर सकते हैं:

{
  'name':'user1',
  'address':' 1 mountain view',
  'phone': '123-324-3308',
  'SSN':'123-45-7891'
}

अब संग्रह में संग्रहीत दूसरा दस्तावेज़ इस प्रारूप का हो सकता है:

{
  'name': ' user2',
  'employeeid': 546789
}

यह बहुत अच्छा है कि आप इन दोनों दस्तावेज़ों को एक ही संग्रह में संग्रहीत कर सकते हैं। हालाँकि, समस्या तब शुरू होती है जब आपको संग्रह से इन दस्तावेज़ों को पुनः प्राप्त करने की आवश्यकता होती है। आप कैसे बताते हैं कि पुनर्प्राप्त दस्तावेज़ में प्रारूप 1 या प्रारूप 2 है? आप जांच सकते हैं कि पुनर्प्राप्त दस्तावेज़ में 'ssn' फ़ील्ड है या नहीं और फिर निर्णय लें। एक अन्य विकल्प दस्तावेज़ के प्रकार को दस्तावेज़ में ही संग्रहीत करना है:

{
  'type': xxx,
  'name': ....
  ...
}

इन दोनों मामलों में आपने जो हासिल किया है वह डेटाबेस से एप्लिकेशन में स्कीमा प्रवर्तन को स्थानांतरित कर रहा है -

हमेशा एक स्कीमा होता है, यह केवल एक प्रश्न है कि इसे कहां कार्यान्वित किया जाता है।

यदि आपके पास सही अनुक्रमणिका है तो यह समस्या को कुछ हद तक कम करता है। यदि आपके अधिकांश प्रश्न 'कर्मचारी' द्वारा हैं, तो आप जानते हैं कि पुनर्प्राप्त दस्तावेज़ हमेशा दूसरे प्रारूप का होता है - हालाँकि, आपके शेष कोड जो इस अनुक्रमणिका का उपयोग नहीं करते हैं, उनमें अभी भी ऊपर उल्लिखित समस्या होगी। इसके अलावा यदि आप नेवले जैसे ODM का उपयोग कर रहे हैं तो यह स्वचालित रूप से पहले से ही आपके लिए MongoDB के शीर्ष पर एक स्कीमा लागू कर देता है।

ऐसे कई अनुप्रयोग हैं जो इस लचीलेपन से लाभान्वित होते हैं। एक परिदृश्य जो दिमाग में आता है वह एक स्कीमा का मामला है जहां कई वैकल्पिक फ़ील्ड/कॉलम हैं। MongoDB में, कुछ लापता कॉलम होने पर कोई जुर्माना नहीं है। प्रत्येक दस्तावेज़ में केवल वही फ़ील्ड हो सकते हैं जिनकी उसे आवश्यकता होती है।

दस्तावेज़ सत्यापन

संस्करण 3.2.x शुरू करना MongoDB अब "सत्यापनकर्ता" निर्माण का उपयोग करके स्कीमा सत्यापन की अवधारणा का समर्थन करता है। यह सत्यापन के कई स्तर प्रदान करता है - ताकि आप उस स्तर को चुन सकें जो आपके लिए काम करता है। यदि आप सत्यापनकर्ता का उपयोग नहीं करते हैं तो डिफ़ॉल्ट व्यवहार पिछले स्कीमा रहित व्यवहार है। आमतौर पर आप संग्रह निर्माण के समय "सत्यापनकर्ता" बनाएंगे

db.createCollection( "contacts",
   { validator: { $or:
      [
         { employeeid: { $exists: true }},
         { SSN: { $exists: true } }
      ]
   }
} )

मौजूदा संग्रह

मौजूदा संग्रह को 'colMod' कमांड का उपयोग करके अपडेट किया जा सकता है:

db.runCommand( {
  collMod: "contacts”,
  validator: { $or: [ { employeeid: { $exists: true }}, { SSN: { $exists:true} } ] }
} )

सत्यापन स्तर

MongoDB 'ValidationLevel' की अवधारणा का समर्थन करता है। डिफ़ॉल्ट सत्यापन स्तर 'सख्त' है, जिसका अर्थ है कि यदि दस्तावेज़ सत्यापन मानदंडों को पूरा नहीं करता है तो प्रविष्टियां और अद्यतन विफल हो जाते हैं। यदि सत्यापन स्तर 'मध्यम' है तो यह सत्यापन मानदंडों को पूरा करने वाले मौजूदा दस्तावेज़ों पर सत्यापन लागू करता है। दस्तावेज़ जो वर्तमान में मौजूद हैं और मानदंडों को पूरा नहीं करते हैं, वे मान्य नहीं हैं। सुविधाजनक होते हुए भी 'मध्यम' सत्यापन स्तर आपको परेशानी में डाल सकता है - इसलिए इसे सावधानी से उपयोग करने की आवश्यकता है।

सत्यापन कार्रवाई

डिफ़ॉल्ट रूप से, सत्यापन क्रिया 'त्रुटि' होती है। यदि आपका दस्तावेज़ सत्यापन में विफल रहता है तो यह एक त्रुटि है और अद्यतन/सम्मिलित विफल रहता है। हालाँकि, आप सत्यापन क्रिया को 'चेतावनी' पर भी सेट कर सकते हैं जो मूल रूप से लॉग में स्कीमा उल्लंघन को लॉग करता है, लेकिन सम्मिलित करने में विफल नहीं होता है।

आपके अगले प्रोजेक्ट में कौन से स्कीमा डिज़ाइन उदाहरण आपकी मदद करेंगे, हमें बताएं!