उपयोगकर्ता, थ्रेड और पोस्ट स्थितियों के साथ अधिक उन्नत मॉडल बनाना

एक ऑनलाइन फ़ोरम के बारे में अपने पहले लेख में, मैंने उल्लेख किया था कि जोड़ने के लिए कई और उन्नत सुविधाएँ हो सकती हैं:

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

फ़ोरम के लिए, मैं थ्रेड से संबंधित संभावित रूप से कई पोस्टिंग वाली बातचीत को संदर्भित करने के लिए "थ्रेड" शब्द का उपयोग करूंगा।

मैं एक प्रारंभिक टिप्पणी करूंगा; मैं आमतौर पर वर्चर फ़ील्ड की लंबाई को परिभाषित करने के लिए 100 या 1000 जैसे गोल संख्याओं का उपयोग करता हूँ; मैं यह सुझाव नहीं दे रहा हूं कि ये आवश्यक रूप से उपयुक्त आकार हैं, लेकिन लंबाई को अपरिभाषित (%) छोड़ने के बजाय, इसे शॉर्टहैंड के रूप में उपयोग कर रहा हूं। दूसरी ओर, मैं कभी-कभी email . जैसे क्षेत्रों के लिए बहुत विशिष्ट लंबाई का उपयोग करता हूं और ip_address; 254 अधिकतम लंबाई है जो एक ईमेल पता RFC परिभाषाओं के अनुसार हो सकता है, जबकि 45 अधिकतम लंबाई है जो एक IPv6 पता हो सकता है।

उपयोगकर्ता विवरण

ऑनलाइन फ़ोरम बनाने पर हमारी लेख श्रृंखला के भाग 1 में, उपयोगकर्ता जानकारी बहुत सीमित थी। मैं संग्रहीत उपयोगकर्ता विवरण को बढ़ाऊंगा। अभी के लिए, मॉडरेशन बहुत बुनियादी होगा:उपयोगकर्ता या तो मॉडरेटर होंगे या नहीं। हम बाद में श्रेणियों और थ्रेड्स से संबंधित अधिक जटिल मॉडरेशन नियम बना सकते हैं।

उपयोगकर्ताओं की स्थिति के लिए, मैं user_status तालिका, ताकि मैं किसी अन्य स्थिति में उसका पुन:उपयोग कर सकूं, भले ही "EMAIL_NOT_VERIFIED", "VERIFIED", और "BLOCKED" जैसी बहुत कम स्थितियां हों।

उपयोगकर्ता निर्माण

मैं उपयोगकर्ता की स्थिति का उपयोग उन उपयोगकर्ताओं को पहचानने के लिए करूंगा जो उपयोगकर्ता द्वारा अपना खाता बनाने के बाद "EMAIL_NOT_VERIFIED" स्थिति में हैं और उनके दिए गए ईमेल पते पर एक ईमेल भेजा गया है, लेकिन इससे पहले कि वे ईमेल में सत्यापन URL पर क्लिक करें। आप और भी पेचीदा हो सकते हैं और "EMAIL_VERIFICATION_TO_BE_SENT" और "EMAIL_VERIFICATION_RESENT" जैसी स्थितियाँ प्राप्त कर सकते हैं यदि इनमें से कुछ चरणों को आपके सिस्टम के विभिन्न घटकों द्वारा नियंत्रित किया जाता है और उपयोगकर्ता निर्माण के दौरान तुरंत नहीं।

थ्रेड और पोस्ट स्थितियां

मॉडरेट की गई पोस्टिंग अन्य उपयोगकर्ताओं के लिए दृश्यमान होने से पहले एक मॉडरेटर द्वारा अनुमोदित होनी चाहिए। पोस्ट और थ्रेड की अलग-अलग स्थितियाँ होंगी जैसे:अनुमोदन की प्रतीक्षा करना, स्वीकृत, स्पैम के रूप में रिपोर्ट करना, अवरुद्ध करना। थ्रेड और पोस्ट की स्थिति के लिए, मैं status टेबल। तब एप्लिकेशन को पता होना चाहिए कि स्टेटस टेबल के भीतर प्रत्येक मान का क्या अर्थ है (यदि स्थिति ="स्वीकृत", थ्रेड प्रदर्शित होता है), लेकिन मैं इसे केवल thread और post टेबल। हमारी कुछ स्थितियां होंगी, जैसे "WAITING_FOR_APPROVAL", "अनुमोदित", "अस्वीकार", "REPORTED_AS_SPAM", और "BLOCKED", और हम भविष्य में और जोड़ना चाह सकते हैं।

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

यह मुझे status थ्रेड और पोस्ट दोनों के लिए तालिका, क्योंकि इन दोनों की स्थितियों का एक ही अर्थ होना चाहिए। मैं status उपयोगकर्ताओं की स्थिति को इंगित करने के लिए तालिका; मुझे नहीं लगता कि यह एक अच्छा डिज़ाइन विकल्प होगा।

औपचारिक डिजाइन

इसलिए, हम भाग 1 में बनाए गए ईआरडी का विस्तार करते हैं। मैंने भाग 1 के लेख में बनाई गई तालिकाओं को पीले रंग में रंगा है और नई जोड़ी गई तालिकाओं को नारंगी रंग में रंगा है ताकि जोड़ों को देखना आसान हो। हालांकि, मैंने तालिकाओं में अलग-अलग परिवर्तनों को चिह्नित नहीं किया है।

आगे क्या?

फिर से, अभी भी अतिरिक्त सुधार किए जाने हैं, लेकिन यहाँ हमने एक बहुत ही सरल ऑनलाइन फ़ोरम लिया है और कई उपयोगी नई सुविधाएँ जोड़ी हैं।

अगले भागों में, मैं अन्य सुविधाओं को जोड़ने पर विचार करूँगा जैसे:

• फोरम श्रेणियां और उप-श्रेणियाँ जहाँ प्रत्येक श्रेणी में एक विषय, कई मॉडरेटर और श्रेणी की निर्माण तिथि जैसी अतिरिक्त जानकारी होती है। एक विषय एक पोस्ट . के लिए सामग्री के अलावा
• और फिर हम उपयोगकर्ताओं को थ्रेड और पोस्ट को वोट करने और वोट करने की अनुमति देना चाहेंगे।

आपके ऑनलाइन फ़ोरम को किन विशेषताओं की आवश्यकता है? इस श्रृंखला का अगला भाग तैयार करते समय क्या कोई ऐसी विशेषताएँ हैं जिन्हें आप चाहते हैं कि मैं ध्यान में रखूँ? अगर ऐसा है, तो मुझे बताएं।