In mijn tweede artikel over een online forum vermeldde ik dat er mogelijk nog meer geavanceerde functies zouden kunnen worden toegevoegd:
- Forum categorieën en subcategorieën waarbij elke categorie een onderwerp heeft, verschillende moderators en aanvullende informatie zoals de aanmaakdatum van de categorie.
- Een post heeft mogelijk een onderwerp naast de inhoud.
- Misschien willen we gebruikers toestaan op te stemmen en stem weg op discussies en berichten.
Om het model gemakkelijker te kunnen begrijpen, hebben we een voorbeeld van zo'n forum voorbereid met categorieën, threads, berichten, enz. We hopen dat dit het gemakkelijker maakt om dingen te begrijpen:
Entiteiten uit deel 1 zijn geel gekleurd en entiteiten uit deel 2 zijn oranje gekleurd. Hier is het huidige databasemodel na de eerste twee artikelen:
Meer details over berichten
In het tweede artikel heb ik alleen relaties toegevoegd aan "status" voor threads en berichten, maar nu zou ik de berichten willen verbeteren met een extra detail dat verder gaat dan alleen eenvoudige inhoud. Voor nu zal ik een "onderwerp" toevoegen voor elk bericht dat kan verschillen van het "onderwerp" van de draad. Met het “onderwerp” (denk aan de onderwerpregel van een e-mail of het onderwerp van een MMS-bericht) kunnen we een verkorte versie van de inhoud weergeven – zoals de eerste regels van een e-mail die wordt weergegeven in Outlook of op uw telefoon. mail. Gebruikers kunnen ook het "onderwerp" van een bericht gebruiken om een opmerking op hoog niveau op te nemen, zoals "Ik ben het niet eens" en vervolgens hun argumenten in het commentaargedeelte van het bericht plaatsen. Dit is een leuke eenvoudige wijziging aan het model.
Categorieën
Nu we onszelf hebben opgewarmd, laten we een nieuw concept (entiteit) toevoegen voor het categoriseren van threads en berichten. Elke categorie wordt gedefinieerd met een naam; elke categorie is gemaakt door een gebruiker en heeft ten minste één moderator onder de gebruikers, plus een paar andere kenmerken zoals de berichten en discussielijnen die we al hebben. We willen categorieën en subcategorieën, dus we zullen toestaan dat categorieën verwijzen naar andere (sub)categorieën.
Omdat ik per categorie meerdere moderators wil hebben, zal ik een tabel maken om categorieën aan groepen gebruikers te koppelen en gebruikers aan die groepen te koppelen. Deze tabel definieert "groepen" van gebruikers, waarvan er één "moderators" zal zijn, maar in de toekomst kan dit worden uitgebreid voor andere soorten groepen.
Stemmen of "Vind ik leuk"
Persoonlijk geef ik er de voorkeur aan om op iets te "stemmen" of "neer te stemmen" in plaats van het gewoon "leuk" te vinden (maar ik denk dat Mark Zuckerberg het daarover niet met me eens is). Ik zal ervoor kiezen om een stemmechanisme te creëren waarmee gebruikers een "stem omhoog" of een "stem omlaag" kunnen uitbrengen. We kunnen ervoor kiezen om stemmen af te wijzen als er geen stemmen omhoog zijn, of om het aantal stemmen te beperken, maar dat is aan de applicatie om te beslissen, de database houdt eenvoudig het aantal stemmen omhoog en omlaag bij.
We kunnen aparte tabellen maken voor stemmen op discussielijnen en stemmen op berichten, maar ik zal ze in dezelfde tabel bewaren met optionele externe sleutels uit de discussielijnen en berichtentabel. Bovendien kies ik ervoor om niet op categorieën te stemmen.
Formeel ontwerp
Voor nu zijn daarmee de wijzigingen aan het model afgerond, zodat we naar het formele ontwerp kunnen kijken. Nogmaals, we breiden de ERD uit die in deel 1 &2 is gemaakt. Wijzigingen die in dit artikel worden beschreven en in het model zijn geïntroduceerd, zijn blauw gekleurd.
Conclusie
Er zijn nog steeds aanvullende verbeteringen die kunnen worden aangebracht, maar hier hebben we onze database voor een online forum in een redelijk compleet ontwerp gemaakt - dit zou de meeste typische online discussieforums ondersteunen.
Welke andere functies heeft uw online forum nodig?
| « Vorig deel |