MongoDB के साथ एक पसंद मतदान प्रणाली का मॉडल कैसे करें

कोई फर्क नहीं पड़ता कि आप अपने समग्र दस्तावेज़ की संरचना कैसे करते हैं, मूल रूप से दो चीजें हैं जिनकी आपको आवश्यकता है। यह मूल रूप से उन लोगों की "गिनती" और "सूची" के लिए एक संपत्ति है, जिन्होंने पहले ही अपनी "पसंद" पोस्ट कर दी है ताकि यह सुनिश्चित किया जा सके कि कोई डुप्लीकेट सबमिट नहीं किया गया है। यहाँ एक बुनियादी संरचना है:

{ 
    "_id": ObjectId("54bb201aa3a0f26f885be2a3")
    "photo": "imagename.png",
    "likeCount": 0
    "likes": []
}

जो भी हो, आपके "फोटो पोस्ट" और जो भी जानकारी आप चाहते हैं, उसके लिए एक अद्वितीय "_id" है, लेकिन फिर अन्य फ़ील्ड जैसा कि उल्लेख किया गया है। यहां "पसंद" संपत्ति एक सरणी है, और यह आपके सिस्टम में "उपयोगकर्ता" ऑब्जेक्ट्स से अद्वितीय "_id" मान रखने वाली है। तो प्रत्येक "उपयोगकर्ता" का अपना विशिष्ट पहचानकर्ता होता है, या तो स्थानीय भंडारण या ओपनआईड या कुछ में, लेकिन एक अद्वितीय पहचानकर्ता। मैं ObjectId के साथ रहूंगा उदाहरण के लिए।

जब कोई किसी पोस्ट को "लाइक" सबमिट करता है, तो आप निम्नलिखित अपडेट स्टेटमेंट जारी करना चाहते हैं:

db.photos.update(
    { 
        "_id": ObjectId("54bb201aa3a0f26f885be2a3"), 
        "likes": { "$ne": ObjectId("54bb2244a3a0f26f885be2a4") }
    },
    {
        "$inc": { "likeCount": 1 },
        "$push": { "likes": ObjectId("54bb2244a3a0f26f885be2a4") }
    }
)

अब $inc ऑपरेशन वहाँ निर्दिष्ट संख्या से "लाइककाउंट" के मूल्य में वृद्धि करेगा, इसलिए 1 से बढ़ाएँ। $push ऑपरेशन भविष्य के संदर्भ के लिए दस्तावेज़ में उपयोगकर्ता के लिए विशिष्ट पहचानकर्ता को सरणी में जोड़ता है।

यहां मुख्य महत्वपूर्ण बात उन उपयोगकर्ताओं का रिकॉर्ड रखना है जिन्होंने मतदान किया और बयान के "क्वेरी" भाग में क्या हो रहा है। अपने स्वयं के अद्वितीय "_id" द्वारा अद्यतन करने के लिए दस्तावेज़ का चयन करने के अलावा, दूसरी महत्वपूर्ण बात यह सुनिश्चित करने के लिए "पसंद" सरणी की जांच करना है कि वर्तमान मतदान उपयोगकर्ता पहले से वहां नहीं है।

रिवर्स केस या "लाइक" को "हटाने" के लिए भी यही सच है:

db.photos.update(
    { 
        "_id": ObjectId("54bb201aa3a0f26f885be2a3"), 
        "likes": ObjectId("54bb2244a3a0f26f885be2a4")
    },
    {
        "$inc": { "likeCount": -1 },
        "$pull": { "likes": ObjectId("54bb2244a3a0f26f885be2a4") }
    }
)

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

निश्चित रूप से आपके आवेदन के किसी अन्य भाग में दस्तावेज़ में दो सौ प्रविष्टियों के साथ एक सरणी को पढ़ना व्यावहारिक नहीं है। लेकिन MongoDB के पास इसे संभालने का एक बहुत ही मानक तरीका है:

db.photos.find(
    { 
        "_id": ObjectId("54bb201aa3a0f26f885be2a3"), 
    },
    { 
       "photo": 1
       "likeCount": 1,
       "likes": { 
          "$elemMatch": { "$eq": ObjectId("54bb2244a3a0f26f885be2a4") }
       }
    }
)

$elemMatch . का यह उपयोग प्रोजेक्शन में केवल वर्तमान उपयोगकर्ता को लौटाएगा यदि वे मौजूद हैं या केवल एक रिक्त सरणी जहां वे नहीं हैं। यह आपके शेष एप्लिकेशन लॉजिक को जागरूक करने की अनुमति देता है कि क्या वर्तमान उपयोगकर्ता ने पहले ही वोट दिया है या नहीं।

यह मूल तकनीक है और आपके लिए वैसे ही काम कर सकती है, लेकिन आपको इस बात की जानकारी होनी चाहिए कि एम्बेडेड सरणियों को असीम रूप से विस्तारित नहीं किया जाना चाहिए, और बीएसओएन दस्तावेजों पर 16 एमबी की एक कठिन सीमा भी है। तो अवधारणा ध्वनि है, लेकिन यदि आप अपनी सामग्री पर 1000 "समान वोट" की अपेक्षा कर रहे हैं तो इसका उपयोग स्वयं नहीं किया जा सकता है। एक अवधारणा है जिसे "बकेटिंग" के रूप में जाना जाता है, जिसे इस उदाहरण में हाइब्रिड स्कीमा डिज़ाइन के लिए कुछ विस्तार से चर्चा की गई है जो एक समाधान को "पसंद" की उच्च मात्रा को संग्रहीत करने की अनुमति देता है। आप इसे यहां मूल अवधारणाओं के साथ उपयोग करने के लिए वॉल्यूम पर ऐसा करने के तरीके के रूप में देख सकते हैं।