उपयोगकर्ताओं को नोटिफिकेशन स्टोर करने के लिए डेटाबेस डिज़ाइन

Question

मैं साहित्य समुदाय वेबसाइट पर काम कर रहा हूं। (screenshot) और मैं यह समझने की कोशिश कर रहा हूं कि उपयोगकर्ताओं को सूचित करने का तरीका कब होता है जब कोई साइट पर पोस्ट की गई किसी चीज़ पर टिप्पणी करता है, जब कोई व्यक्ति एक नया साहित्य peice, सबमिशन देख रहा है,

मैं समझने की कोशिश कर रहा हूं इस जानकारी को स्टोर करने के लिए डेटाबेस को कैसे व्यवस्थित करें। मैं दो संभावित विचारों के साथ आया हूँ।

1. स्टोर दर्ज करना पड़ा हुआ वस्तु के लिए एक लिंक, एक क्षेत्र कार्य का प्रकार (नई, अद्यतन, आदि) है कि उपयोगकर्ता के बारे में सूचित किया जा रहा है का वर्णन। यह जटिल प्रदर्शन कोड के लिए बनाता है लेकिन इसका मतलब है कि मैं बदल सकता हूं कि अधिसूचनाएं आसानी से कैसे काम करती हैं। यह डेटाबेस में खींचने के लिए आवश्यक डेटा को भी बढ़ाता है जब तक कि मैं तालिका में प्रासंगिक विशेषताओं के हैश को डंप करने के लिए कैश फ़ील्ड का उपयोग नहीं करता।

   • notifiable_type
   • notifiable_id
   • user_id
   • कार्रवाई
   • notifiable_cache

2. (वैकल्पिक, चयनित दर्ज करना पड़ा हुआ वस्तु की विशेषताओं के हैश संग्रहीत करता है) ईमेल और जैसे सूचनाएं इलाज उन्हें किसी विषय और संदेश के साथ डेटाबेस में सहेजें। इसका परिणाम एक साधारण दृश्य में है लेकिन एक जटिल मॉडल है और मुझे आसानी से बदलने से रोकता है कि अधिसूचनाएं कैसे काम करती हैं।

   • user_id
   • शीर्षक
   • संदेश

मैं अन्य विचारों और दो मैं उपरोक्त पर टिप्पणियों के लिए देख रहा हूँ।

Answer 1

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

यदि, हालांकि, अधिसूचनाओं को बदलने की संभावना नहीं है, तो दूसरा विकल्प लागू करना आसान हो सकता है।

Answer 2

मुझे पूरी तरह से यकीन नहीं है कि # 1 में "कार्रवाई" फ़ील्ड क्या है, लेकिन यदि मैं आपकी ज़रूरत को सही ढंग से समझता हूं, तो आप अनिवार्य रूप से उपयोगकर्ताओं को अधिसूचनाओं की कतार में सदस्यता लेना चाहते हैं, है ना? क्या इन अधिसूचनाओं को ईमेल के माध्यम से उपयोगकर्ता को भेजा जाना है, या केवल लॉगिन करते समय प्रदर्शित किया गया है, या दोनों?

मैं वास्तव में इस कतार के रूप में सोचने का लुत्फ उठाऊंगा, जहां आप अधिसूचनाएं प्रकाशित कर रहे हैं, और उपयोगकर्ता इसके साथ जुड़े उपयोगकर्ता_आईडी के साथ किसी भी अधिसूचना में "सब्सक्राइब किए गए" हैं। एक रिलेशनल स्कीमा में, आप शायद # 1 जैसे कुछ का उपयोग करना चाहते हैं, जहां आपके पास किसी उपयोगकर्ता से जुड़े किसी प्रकार के साथ अधिसूचना है। निश्चित रूप से उपयोगकर्ता_आईडी पर इंडेक्स यह सुनिश्चित करने के लिए कि आप उनकी सूचनाएं तुरंत प्राप्त कर सकें। यदि आप इसे बहुत पूछताछ करेंगे, तो आपको प्रदर्शन उद्देश्यों के लिए जो कुछ भी चाहिए, उसे कैश करना बहुत समझ में आता है ताकि आपको किसी भी अन्य टेबल में शामिल होने की आवश्यकता न हो - यह मानते हुए कि प्रदर्शन डेटा बदल नहीं सकता है अधिसूचना 'भेजी गई' है।

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

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

एक और विकल्प आपके rdbms के बाहर अधिसूचनाओं को रखना है। सूचनाओं को memcached में रखने पर विचार करें, उदाहरण के लिए, यदि उन्हें खोने की संभावना स्वीकार्य है (उदाहरण के लिए सर्वर नीचे चला जाता है)। या रेडिस (http://code.google.com/p/redis/) देखें, जो इस समस्या को बहुत आसान बना देगा - स्टोर अधिसूचनाएं, और प्रत्येक उपयोगकर्ता के लिए एक सेट बनाएं, और आप लगभग पूरा कर चुके हैं।

बस कुछ विचार, उम्मीद है कि वे उपयोगी हैं।

Answer 3

message : 
-id_message(pk) 
-to 
-from 
-subject 
-message 
-status (read,unread) 

reply_message : 
-id_reply(pk) 
-id_message 
-from 
-message 
-status (read,unread) 

notification : 
-id_user 
-id_notify(pk) 
-notify_type (message, or reply_message) 
-notify_desc (comment/reply on your message) 
-status (look,unlook) 

notify_detail : (for notify, when user reply or comment more than 1) 
-id_notify 
-id_sender 
-id_detail (input id_message, id_reply) 

कैसे इस बारे में? आप इसे टिप्पणी या टिप्पणी टिप्पणी के साथ मिश्रण कर सकते हैं।

Answer 4

मैंने हाल ही में आईओएस ऐप के रेल बैकएंड में ऐसा किया और मूल रूप से (2) टाइमस्टैम्प के साथ उपयोग किया लेकिन उपयोगकर्ता द्वारा अनुक्रमित एक रेडिस सूची में संग्रहीत किया गया। कमजोर स्कीमा (मूल रूप से 'संदेश' में भरवां सब कुछ के साथ) हम विकास और प्रारंभिक बीटा के दौरान बहुत तेज़ी से आगे बढ़ने देते हैं।

इसके अलावा, अधिसूचनाओं को रेडिस सूची से हटा दिया गया है, इसलिए पुराने प्रारूपों के बारे में चिंता करने के लिए बहुत पुराने संदेश नहीं हैं, खासकर यदि आप 'पुराने' संदेशों को छीन सकते हैं।

Answer 5

मैं एक परियोजना के रूप में अच्छी तरह से सूचनाओं का उपयोग पर काम कर रहा हूँ, मुझे यकीन है कि अगर आप मिल गया तुम्हारा या अब के द्वारा हल अगर यह मदद कर सकता है नहीं कर रहा हूँ, लेकिन इस तालिका संरचना मैं प्रयोग किया जाता है:

Notifications: 
- ID (PK) 
- recipient_id 
- sender_id 
- activity_type ('comment on a post', 'sent friend request', etc) 
- object_type ('post', 'photo', etc) 
- object_url (to provide a direct link to the object of the notification in HTML) 
- time_sent 
- is_unread