एक संदेश प्रणाली के लिए डेटाबेस मॉडल

लोग संवाद करना पसंद करते हैं। हम अक्सर मजाक करते हैं कि कोई भी सॉफ्टवेयर सिस्टम हमेशा एक मैसेजिंग सिस्टम में विकसित होता है। यह लेख संदेश प्रणाली के लिए डेटा मॉडल डिजाइन करने के लिए सिस्टम आवश्यकताओं और चरण-दर-चरण दृष्टिकोण की व्याख्या करेगा।

संक्षेप में आवश्यकताएँ

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

यह प्रणाली प्राप्तकर्ताओं को प्रतिक्रिया . की अनुमति देती है संदेशों को। यह इस बात पर भी नज़र रखता है कि किसने संदेश पढ़ा है और किसने नहीं।

इसके अतिरिक्त, सिस्टम में एक अंतर्निहित अनुस्मारक है ऐसा तंत्र जो प्रेषक को एक रिमाइंडर बनाने की अनुमति देता है, और फिर उसके अनुसार सभी प्राप्तकर्ताओं को एक रिमाइंडर भेजता है।

संस्थाएं और संबंध

इस डेटा मॉडल में, user और message उपयोगकर्ताओं और संदेशों के विवरण संग्रहीत करने वाली मुख्य संस्थाएं हैं।

user तालिका उपयोगकर्ता से संबंधित विशेषताएँ होंगी जैसे first_name , last_name , आदि.

message . में कुछ स्व-व्याख्यात्मक स्तंभ तालिका subject होगी , message_body , create_date और expiry_date . मैं creator_id . नामक एक विदेशी कुंजी कॉलम भी जोड़ता हूं इस तालिका में id . को संदर्भित करता है user टेबल। जैसा कि इसके नाम से पता चलता है, यह संदेश के निर्माता की आईडी को दर्शाता है। चूंकि संदेश के लिए हमेशा एक निर्माता होता है, इसलिए मैं इस कॉलम को केवल संदेश तालिका में रखता हूं। आप सोच रहे होंगे कि expiry_date क्यों है तालिका में स्तंभ। मैंने इस कॉलम को एक संदेश पर रिमाइंडर प्रबंधित करने के लिए जोड़ा है। मैं इस कॉलम के बारे में इस लेख में बाद में विस्तार से बताऊंगा।

इस डेटा मॉडल में सबसे महत्वपूर्ण तालिका है message_recipient . मैं कहूंगा कि संपूर्ण डेटा मॉडल केवल इसी तालिका के इर्द-गिर्द घूमता है। इस तालिका को बनाने के पीछे मुख्य उद्देश्यों में से एक है संदेशों और उनके प्राप्तकर्ताओं के बीच मानचित्रण को रोकना। इस प्रकार recipient_id इस तालिका में कॉलम प्राप्तकर्ताओं की आईडी को दर्शाता है, और यह कॉलम user टेबल।

जब एक प्राप्तकर्ता को संदेश भेजा जाता है, तो इस तालिका में प्राप्तकर्ता की आईडी के साथ recipient_id में एक रिकॉर्ड डाला जाएगा। कॉलम।

अब आप सोच रहे होंगे कि recipient_group_id क्या है? कॉलम इस तालिका में दर्शाता है। यहां, मुझे पहले यह बताना चाहिए कि इस मॉडल को एक साथ कई प्राप्तकर्ताओं को संदेश भेजने की आवश्यकता के लिए कैसे बढ़ाया जा सकता है।

समूह को संदेश भेजना

मुझे एक और टेबल चाहिए, जिसका नाम है group , समूह विवरण रखने के लिए। चूंकि user और group टेबल, यानी एक उपयोगकर्ता एक से अधिक समूहों का हिस्सा हो सकता है, मैं user_group ।

उदाहरण के लिए, यदि 25 उपयोगकर्ताओं के साथ एक समूह बनाया जाता है, तो user_group टेबल।

आइए message_recipient टेबल। मैं user_group message_recipient टेबल। मैं इसे नाम देता हूं recipient_group_id . यह कॉलम उस उपयोगकर्ता-समूह का मान रखेगा जिसके लिए संदेश भेजा गया है।

अब जब भी किसी समूह को कोई संदेश भेजा जाता है, तो message_recipient समूह में उपयोगकर्ताओं की संख्या और recipient_group_id . के आधार पर तालिका तदनुसार उन सभी अभिलेखों के विरुद्ध लॉग किया जाएगा।

मैं इसे एक उदाहरण के साथ और स्पष्ट करता हूं। मान लीजिए 10 लोगों के समूह को एक संदेश भेजा जाता है। इस मामले में, कुल 10 रिकॉर्ड, प्रत्येक के लिए एक recipient_group_id समूह का, message_recipient टेबल।

कृपया ध्यान दें कि यदि संदेश किसी उपयोगकर्ता को भेजा जाता है, समूह को नहीं, तो recipient_group_id कॉलम खाली रहता है। इस मामले में, प्रत्यक्ष user_id recipient_id . के तहत लॉग किया जाएगा कॉलम।

मैं is_read नामक एक और कॉलम जोड़ूंगा तालिका में एक संदेश-उपयोगकर्ता के विरुद्ध ध्वज धारण करने के लिए जो यह दर्शाता है कि संदेश उपयोगकर्ता द्वारा पढ़ा गया है या नहीं।

अद्वितीय कुंजी message_recipient टेबल - कॉलम message_id . पर एक कंपोजिट यूनीक की होनी चाहिए , recipient_id और recipient_group_id , यह सुनिश्चित करने के लिए कि इन स्तंभों के अद्वितीय संयोजन के लिए केवल एक रिकॉर्ड मौजूद है।

मैं is_active रखता हूं अभिलेखों के 'सॉफ्ट डिलीट' को सक्षम करने के लिए, संदेश और संदेश_प्राप्तकर्ता तालिकाओं को छोड़कर सभी तालिकाओं में कॉलम। चूंकि मैंने एक expiry_date जोड़ा है संदेश तालिका में कॉलम, एक is_active कॉलम की जरूरत नहीं है। इसके अलावा, message_recipient तालिका क्योंकि एक संदेश भेजे जाने के बाद उसे सीधे वापस नहीं किया जा सकता है। हालांकि कोई भी expiry_date . को अपडेट करके इसे निष्क्रिय बना सकता है संदेश के लिए अतीत में एक तारीख के लिए।

संदेश का जवाब देना

अब मान लीजिए कि सिस्टम उपयोगकर्ताओं को प्राप्त संदेशों का जवाब देने की अनुमति देता है। मैं उसी तालिका का विस्तार करता हूं message उत्तरों के लिए एक नई तालिका बनाने के बजाय इस आवश्यकता को पूरा करने के लिए। मैं parent_message_id नामक एक कॉलम जोड़ूंगा संदेशों के बीच एक श्रेणीबद्ध संबंध स्थापित करने के लिए। मैं उत्तर संदेश के लिए एक नया रिकॉर्ड सम्मिलित करूंगा, और parent_message_id . को अपडेट करूंगा/करूंगी उत्तर संदेशों के लिए कॉलम। यह मॉडल n-स्तर के पदानुक्रमित संबंध का समर्थन करता है, अर्थात उत्तर संदेश पर उत्तर को भी इस मॉडल के माध्यम से ट्रैक किया जा सकता है।

प्रत्येक संदेश का 'पढ़ें%' देखने के लिए डैशबोर्ड

is_read प्रत्येक संदेश-उपयोगकर्ता रिकॉर्ड के विरुद्ध ध्वज लॉग किया जाता है। उपयोगकर्ता द्वारा संदेश पढ़े जाने तक इस ध्वज का मान शून्य रहता है। जैसे ही उपयोगकर्ता संदेश पढ़ेगा, इसे ONE में अपडेट कर दिया जाएगा। कॉलम मान के आधार पर, समूह को भेजे जाने वाले संदेश के लिए 'रीड%' निर्धारित किया जा सकता है।

मुझे ऐसी रिपोर्ट लाने के लिए एक नमूना SQL लिखने दें:

SELECT msg.subject, sent_to, 
       msg.create_date, (summ / countt) * 100 AS Read_Per
FROM (SELECT msg.subject, grp.name as sent_to,  msg.create_date, 
      SUM (is_read) AS summ, COUNT (is_read) AS countt
      FROM message_recipient msgrec,  message msg,  
           user_group ug,  group grp
      WHERE  msgrec.message_id = msg.id
      AND msgrec.recipient_group_id = ug.id
      AND ug.GROUP_ID = grp.id
      AND msgrec.recipient_group_id IS NOT NULL
      GROUP BY msg.subject, grp.name, msg.create_date
      UNION
      SELECT msg.subject, u.first_name || ' ' || u.last_name as sent_to,
      msg.create_date, SUM (is_read) AS summ, COUNT (is_read) AS countt
      FROM message_recipient msgrec, MESSAGE msg,  user u
      WHERE msgrec.message_id = msg.id
      AND msgrec.recipient_id = u.id
      AND msgrec.recipient_group_id IS NULL
      GROUP BY msg.subject, name, msg.create_date);

याद दिलाना तंत्र

याद दिलाने की कार्यक्षमता के लिए, मैं संदेश तालिका में निम्नलिखित कॉलम जोड़ूंगा:

• Is_reminder - यह कॉलम बताता है कि संदेश के लिए अनुस्मारक की आवश्यकता है या नहीं।
• Reminder_frequency_id - यह कॉलम रिमाइंडर की फ्रीक्वेंसी को दर्शाता है। क्या यह दैनिक आधार पर या साप्ताहिक आधार पर होना चाहिए?
• Next_remind_date - इस कॉलम में वह तारीख होती है जब अगला रिमाइंडर भेजने की जरूरत होती है। रिमाइंडर next_remind_date को भेजा जाएगा उन उपयोगकर्ताओं के लिए जिनके लिए 'is_read' ध्वज अभी भी शून्य है। हर बार रिमाइंडर भेजे जाने पर इस कॉलम के लिए एक नए मान की गणना की जाएगी।
• Expiry_date - यह कॉलम कट-ऑफ तारीख है जब उपयोगकर्ताओं को रिमाइंडर नहीं भेजे जाएंगे।

next_remind_date . की गणना इस प्रकार होगा - मान लीजिए कि 9/14, सोमवार को उपयोगकर्ताओं को एक संदेश 10/5 के साथ समाप्ति तिथि के रूप में भेजा जाता है। संदेश अनुस्मारक की साप्ताहिक आवृत्ति के साथ भेजा जाता है। इस मामले में, उपयोगकर्ताओं को ईमेल पर जवाब देने के लिए 9/21 और 9/28 को रिमाइंडर भेजे जाएंगे, और आखिरी बार 10/5 को उन्हें अगले 24 घंटों में जवाब देने का आग्रह करने के लिए भेजा जाएगा।

अंतिम डेटा मॉडल

निष्कर्ष

इस मैसेजिंग सिस्टम का सबसे अच्छा उपयोग उन उपयोगकर्ताओं को सूचनाएं भेजना है जो लंबे समय से सिस्टम में निष्क्रिय हैं। इन सूचनाओं को एक सक्षम अनुस्मारक तंत्र के साथ भेजा जा सकता है, और उपयोगकर्ताओं को सूचनाएं तब तक भेजी जाएंगी जब तक उपयोगकर्ता अधिसूचना का जवाब नहीं देते। यदि उपयोगकर्ताओं से सूचनाओं का कोई जवाब नहीं मिलता है, तो समाप्ति तिथि को और उसके बाद उपयोगकर्ताओं को निष्क्रिय कर दिया जाएगा।

मैं पूरी तरह कार्यात्मक संदेश प्रणाली के लिए एक डेटा मॉडल बनाने का इरादा रखता हूं, जो संदेश/सूचनाएं भेजने के लिए विभिन्न प्रणालियों में फिट हो सकता है। लेख पर अपने विचार/इनपुट/टिप्पणियां साझा करने के लिए स्वतंत्र महसूस करें।