Database
 sql >> डेटाबेस >  >> RDS >> Database

श्रेणियों को प्रबंधित करना और थ्रेड और पोस्ट पर वोटिंग जैसी अधिक उन्नत सुविधाएँ जोड़ना

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

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

मॉडल को अधिक आसानी से समझने में सक्षम होने के लिए, हमने श्रेणियों, थ्रेड्स, पोस्ट आदि के साथ ऐसे फ़ोरम का एक उदाहरण तैयार किया है। हम आशा करते हैं कि इससे चीजों को समझना आसान हो जाएगा:

भाग 1 की इकाइयां पीले रंग में और भाग 2 की इकाइयां नारंगी रंग में रंगी गई हैं। यहाँ पहले दो लेखों के बाद का वर्तमान डेटाबेस मॉडल है:




पोस्ट के बारे में अधिक जानकारी

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

श्रेणियां

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

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

मतदान या "पसंद"

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

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

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

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




निष्कर्ष

अभी भी अतिरिक्त सुधार किए जा सकते हैं, लेकिन यहां हमने एक ऑनलाइन फ़ोरम के लिए अपने डेटाबेस को पूरी तरह से पूर्ण डिज़ाइन में बनाया है - यह सबसे विशिष्ट ऑनलाइन चर्चा मंचों का समर्थन करेगा।

आपके ऑनलाइन फ़ोरम को और किन विशेषताओं की आवश्यकता है?

« पिछला भाग  


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Azure स्वचालन के तरीके

  2. उत्पादन भंडार से परीक्षण वातावरण बनाना

  3. बार्कर का अंकन

  4. Sp_prepare / sp_prepexec . के लिए उपयोग का मामला

  5. इसके लिए एक समाधान:कर्सर उस तालिका पर समर्थित नहीं हैं जिसमें क्लस्टर्ड कॉलमस्टोर इंडेक्स है