फेसबुक और जीमेल जैसे थ्रेडेड प्राइवेट मैसेजिंग सिस्टम बनाना

Question

मैं एक थ्रेडेड मैसेज सिस्टम बना रहा हूं जो जीमेल और फेसबुक की तरह है जहां इनबॉक्स सबसे हालिया संदेश का विषय, प्रेषक का नाम और टाइम-स्टैम्प प्रदर्शित करता है। ।

users: 
    user_id 
    user_name 

thread: 
    thread_id 
    title 
    to_id 
    to_keep 
    to_read 
    from_id 
    from_keep 
    date 

message: 
    message_id 
    thread_id 
    to_id 
    from_id 
    message_text 
    date 

क्या मैं अभी कर रहा हूँ जब कोई उपयोगकर्ता एक नया संदेश बनाता है, यह धागा तालिका में एक नया धागा और उसके बाद एक नया संदेश में बनाता है:

यहाँ कैसे मेरी टेबल की स्थापना कर रहे हैं संदेश तालिका और यदि कोई उपयोगकर्ता किसी धागे का जवाब देता है, तो यह थ्रेड तालिका में वर्तमान थ्रेड को डुप्लिकेट करता है, सिवाय इसके कि यह to_id और from_id को स्वैप करता है और फिर उस पर आधारित एक नया संदेश बनाता है।

इसके अलावा, इनबॉक्स दृश्य के लिए, मैं केवल user_id पर आधारित सभी थ्रेडों को क्वेरी करने में सक्षम हूं। तो SELECT * FROM thread WHERE to_id = 2 and to_keep = TRUE ORDER BY date DESC जैसे कुछ या यदि मैं आउटबॉक्स में संदेश देखना चाहता हूं तो यह SELECT * FROM thread WHERE from_id = 2 and from_keep = TRUE ORDER BY date DESC जैसा कुछ होगा।

यदि कोई नया संदेश होता है तो कोई उपयोगकर्ता धागा खोलता है, तो to_read को UPDATE thread SET to_read = TRUE WHERE thread_id = 4 पर अपडेट किया जाता है।

मुझे लगता है कि मैं इस प्रक्रिया को जटिल बना रहा हूं और यह करने का एक बेहतर तरीका होना चाहिए।

किसी भी मदद या विचारों की सराहना की जाएगी।

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

Answer 1

आप प्रत्येक संदेश के उपयोगकर्ता के दृष्टिकोण से संदेश संबंध अलग क्यों नहीं करते?

मैं संदेश पर एक आत्म-संदर्भ संबंध द्वारा थ्रेडिंग करता हूं। दूसरे शब्दों में, संदेश में "respond_to_message_id" कॉलम है।

मुझे यकीन नहीं है कि मैं समझता हूं कि आपके पास "to_id" क्यों है। संदेश व्यक्तिगत उपयोगकर्ताओं को निर्देशित हैं? यह बहुत सीमित लगता है। मुझे लगता है कि आपके पास कोई प्राप्तकर्ता नहीं होगा (यानी प्राप्तकर्ता एक संदेश बोर्ड है जिसे कोई भी पढ़ सकता है) या आपके पास एक ई-मेल की तरह, एकाधिक प्राप्तकर्ता निर्दिष्ट करने की क्षमता होगी। शायद आप इस बारे में और बता सकते हैं कि सिस्टम का उपयोग कैसे किया जाए।

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

इस तरह, यदि आप जानना चाहते हैं कि उपयोगकर्ता ने कोई संदेश पढ़ा है या नहीं, तो दिए गए संदेश के लिए छेड़छाड़ तालिका में उपयोगकर्ता आईडी को पढ़ने का प्रयास करें। यदि यह नहीं है, तो वह संदेश उस उपयोगकर्ता द्वारा अपठित नहीं है।

ध्यान दें कि यदि आप एकल डिज़ाइनर प्राप्त करना चाहते हैं तो यह डिज़ाइन है और यदि आप एकाधिक प्राप्तकर्ता चाहते हैं तो आप प्रत्येक संदेश के लिए प्राप्तकर्ताओं की सूची रखने के लिए एक चौराहे तालिका का उपयोग कर सकते हैं। यदि आपके पास प्राप्तकर्ता चौराहे तालिका है, तो यह आपकी पढ़ी स्थिति तालिका के रूप में डबल-ड्यूटी कर सकती है।

संपादित करें: ERD स्केच:

यहाँ मैं किस बारे में बात कर रहा हूँ की एक त्वरित स्केच है ...

या नहीं, इस संदेश को रखने के लिए चुना गया है संदेश पर ही ध्वजांकित है। अगर संदेश एक नए धागे की शुरुआत है, तो answer_to_message_id कॉलम पूर्ण है, अन्यथा यह मूल संदेश का संदेश_आईडी है। मल्टीप्लेंट प्राप्तकर्ता हो सकते हैं, जिनमें से प्रत्येक को संदेश रखने या नहीं, साथ ही प्राप्तकर्ता संदेश को पढ़ते समय दिनांक और समय को ट्रैक करने की क्षमता रखता है।

संपादित करें 2: वैकल्पिक ERD और के लिए सबसे हाल ही में संदेश

@OP का पता कर एक सूत्र में सबसे हाल के संदेश के लिए क्वेरी करने के लिए कैसे पूछा। जवाब धागे के रूप पर निर्भर करता है। आप या तो एक फ्लैट थ्रेड कर सकते हैं जहां प्रत्येक संदेश संदेशों की रैखिक धारा के अंत में जाता है या आपके पास पेड़ के आकार का धागा हो सकता है जहां प्रत्येक संदेश में एक विशिष्ट माता-पिता होता है, जब तक यह धागे की जड़ न हो। उपरोक्त ईआरडी में, answer_to_message_id फ़ील्ड का उपयोग किसी भी तरह से किया जा सकता है। अगर धागा सपाट है, तो एफके हमेशा रूट संदेश पर है। यदि धागा पेड़ के आकार का है, तो एफके उत्तर संदेश के तत्काल माता-पिता के लिए है।

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

select top 1 
    M.message_id 
, M.sent_datetime 
, M.title 
, M.message_text 
, S.user_id 
, S.user_name 
-- and anything else you want... 
from MESSAGE M inner join USER S 
    on M.sender_user_id = U.user_id 
where M.reply_to_message_id = @ThreadRootMessageID 
order by 
    M.sent_datetime desc 

हैं, तो दूसरी ओर, अपने धागे पेड़ के आकार का है और यह एक प्रश्न आप जल्दी और आसानी से चलाने के लिए सक्षम होना चाहता हूँ है, तो ऊपर ईआरडी में स्कीमा के साथ काम करना बहुत आसान नहीं है। एसक्यूएल पेड़ पर अच्छा नहीं है। आप समस्या को हल करने के लिए समस्या का समाधान कर सकते हैं। नीचे ERD देखें:

नोट अब एक FK है कि वहाँ तत्काल माता पिता और एक FK दिखाने के लिए रूट को दिखाने के लिए। चूंकि धागे संपादन के अधीन नहीं हैं - कम से कम संपादित करने के लिए जहां एक संदेश की जड़ एक अलग धागे पर इंगित करने के लिए बदल जाती है, यह अनौपचारिकता अद्यतन विसंगतियों का जोखिम नहीं दर्शाती है, इसलिए अनावश्यकता बहुत ही समस्याग्रस्त नहीं है।

यदि आप इस ईआरडी का उपयोग करते हैं तो "थ्रेड एक्स में सबसे हालिया संदेश" के लिए क्वेरी उपरोक्त जैसा ही है, लेकिन M.reread_ro__essage_id के बजाय जहां क्लॉज में M.thread_root_message_id के साथ क्वेरी है।