MongoDB की कुंजी में `.` के साथ JSON दस्तावेज़ सम्मिलित करना


14

सबसे पहले, यह एक प्रोग्रामिंग प्रश्न की तुलना में एक डिजाइन प्रश्न का अधिक है।

मैं एक एप्लिकेशन बना रहा हूं जहां मुझे मौजूदा JSON डेटा प्राप्त करना है और इसे MongoDB में सम्मिलित करना है। मैंने पाया कि JSON के कुछ दस्तावेजों .में उनकी कुंजी की अवधि है। मैं MongoDB दस्तावेज़ में पढ़ता हूं कि MongoDB .में कुंजियों की अनुमति नहीं है क्योंकि वे क्वेरी के लिए उपयोग की जाती हैं।

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

इसलिए, मेरी आवश्यकताओं को देखते हुए, मेरे पास JSON दस्तावेज़ को संग्रहीत करने के दो विकल्प हैं:

  1. कुंजियों में अवधि के लिए JSON के माध्यम से खोजें और उन्हें छोड़ दें और फिर उन्हें MongoDB में डालें।
  2. पूरे JSON को BSON प्रारूप में रूपांतरित करें और उन्हें इस तरह संग्रहीत करें, जिससे बचने की आवश्यकता से बचा जा सके, और MongoDB के बाहर जरूरत पड़ने पर मैन्युअल रूप से JSON को पार्स कर सके।

क्या आप मुझे बता सकते हैं कि कौन सा बेहतर डिजाइन होगा, क्योंकि मैं किसी निष्कर्ष पर नहीं पहुंच पा रहा हूं।


इसे हल करने का एक तरीका इन्सर्ट विधि का उपयोग करना और check_keys पैरामीटर को गलत पर सेट करना है। एक अन्य तरीका यह है कि आप अपने दस्तावेज़ से गुजरें और शापित डॉट की प्रत्येक घटना को किसी अन्य चीज़ या किसी समान यूनिकोड वर्ण (अच्छी तरह से, वर्ण) से बदल दें।
नूह

जवाबों:


3

कुछ विकल्प हैं:

1. एक डैश द्वारा डॉट्स को बदलें।

यह मेरा पसंदीदा दृष्टिकोण होगा, क्योंकि यह संरचना को पर्याप्त रूप से स्पष्ट रखता है।

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

2. U + FF0E जैसे यूनिकोड डॉट कैरेक्टर द्वारा डॉट्स को बदलें

मैं इस दृष्टिकोण के खिलाफ दृढ़ता से सलाह दूंगा, क्योंकि इससे सड़क पर बड़े पैमाने पर डिबगिंग सिरदर्द हो सकते हैं । कोई व्यक्ति जो परिणामी JSON का उपयोग कोड में कहीं दूर MongoDB से करता है, यह अनुमान लगाने के लिए कि एक डॉट वास्तव में एक डॉट नहीं है, किसी के समय के सचमुच हफ्तों को बर्बाद करने का एक अच्छा तरीका है। ऐसे यूनिकोड के ट्रिक को हैकर्स के पास रखें जो किसी को यह सोचकर धोखा देना चाहते हैं कि एक चरित्र एक अलग है।

3. BSON का उपयोग करें।

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

सामान्य तौर पर, दोष यह है कि आप दस्तावेज़ के माध्यम से खोज नहीं कर पाएंगे या इसका केवल एक हिस्सा लोड नहीं कर पाएंगे।

4. एक मानक एन्कोडिंग का उपयोग करें, जैसे बेस 64।

समस्याग्रस्त कुंजियों (या सभी कुंजियों, समस्याग्रस्त और गैर-समस्याग्रस्त लोगों के बीच के अनुपात के आधार पर) को6464 या हेक्साडेसिमल में बदलना एक व्यवहार्य समाधान हो सकता है, बल्कि स्पष्ट होने के लाभ के साथ: अधिकांश डेवलपर्स एक नज़र में बेस 64 या हेक्साडेसिमल मानों को पहचान लेंगे। ।

दोष यह है कि मेमोरी फ़ुटप्रिंट, साथ ही उपयोग करते समय कुंजी को एनकोड और डीकोड करने की आवश्यकता है।

5. पर सेट check_keysकरें false

मैं इस दृष्टिकोण के खिलाफ दृढ़ता से सलाह दूंगा, क्योंकि यह डेटा क्वेरी को अस्पष्ट बना देगा, और घंटों या दिनों को यह जानने की कोशिश करेगा कि एक विशिष्ट क्वेरी वह क्यों नहीं करता है जो आपने कल्पना की थी कि उसे क्या करना चाहिए। डॉट एक आरक्षित वर्ण है और आपकी रक्षा के लिए चेक यहाँ है; MongoDB को चेक छोड़ने के लिए कहकर, आप केवल उस क्षण को स्थगित कर देंगे, जहाँ आपको MongoDB के सिंटैक्स और एक कुंजी में प्रयुक्त आरक्षित वर्ण के बीच संघर्ष से निपटना होगा।


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.