In mijn eerste artikel over een online forum zei ik dat er mogelijk nog meer geavanceerde functies zijn om toe te voegen:
- Meer formele details over de gebruiker in plaats van een enkel "naam" veld. Mogelijk wilt u de voornaam, achternaam en gebruikersnaam of bijnaam van de gebruiker. Een mooi forum zou gebruikers ook in staat stellen om een profielfoto, e-mail, rollen, status (om gebruikers te blokkeren) en andere informatie, zoals wanneer ze het forum voor het laatst hebben bezocht.
- Extra controle met betrekking tot het maken van gebruikers zodat we kunnen volgen wanneer een nieuwe gebruiker is aangemaakt, maar voordat zijn/haar e-mailadres is bevestigd.
- Forum categorieën en subcategorieën waarbij elke categorie een onderwerp heeft, verschillende moderators en aanvullende informatie zoals de aanmaakdatum van de categorie. Een onderwerp voor een bericht naast de inhoud
- Gemodereerde berichten die moeten worden goedgekeurd door een moderator voordat ze zichtbaar zijn voor andere gebruikers. Berichten en discussielijnen zouden verschillende statussen hebben, zoals:wachten op publicatie, gepubliceerd, gerapporteerd als spam, geblokkeerd, gedeblokkeerd.
- En dan willen we misschien toestaan dat gebruikers op stemmen en stem weg discussies en berichten.
Voor het forum zal ik de term "thread" gebruiken om te verwijzen naar een gesprek met mogelijk meerdere berichten die verband houden met de thread.
Ik zal een openingsopmerking maken; Ik gebruik over het algemeen ronde getallen zoals 100 of 1000 om de lengte van varchar-velden te definiëren; Ik suggereer niet dat dit noodzakelijkerwijs de juiste maat is, maar gebruik dit als steno, in plaats van de lengte ongedefinieerd te laten (%). Aan de andere kant gebruik ik af en toe zeer specifieke lengtes voor velden zoals email
en ip_address
; 254 is de maximale lengte die een e-mailadres kan hebben volgens de RFC-definities, terwijl 45 de maximale lengte is die een IPv6-adres kan zijn.
Gebruikersgegevens
In deel 1 van onze serie artikelen over het bouwen van het online forum was de gebruikersinformatie zeer beperkt. Ik zal de gebruikersgegevens die worden opgeslagen verbeteren. Voor nu zal moderatie erg basic zijn:gebruikers zullen de moderator zijn of niet. Mogelijk maken we later meer gecompliceerde moderatieregels met betrekking tot categorieën en discussielijnen.
Voor de status van gebruikers zal ik de user_status
tabel, zodat ik die in een andere situatie opnieuw kan gebruiken, zelfs als er maar heel weinig statussen zijn, zoals "EMAIL_NOT_VERIFIED", "VERIFIED" en "BLOCKED".
Gebruikers aanmaken
Ik zal de gebruikersstatus gebruiken om gebruikers te herkennen die de status "EMAIL_NOT_VERIFIED" hebben nadat een gebruiker zijn account heeft aangemaakt en een e-mail is verzonden naar het opgegeven e-mailadres, maar voordat ze op de verificatie-URL in de e-mail hebben geklikt. U kunt zelfs lastiger worden en statussen krijgen zoals "EMAIL_VERIFICATION_TO_BE_SENT" en "EMAIL_VERIFICATION_RESENT" als sommige van deze stappen worden uitgevoerd door verschillende componenten in uw systeem en niet onmiddellijk tijdens het maken van gebruikers.
Thread- en berichtstatussen
Gemodereerde berichten moeten worden goedgekeurd door een moderator voordat ze zichtbaar zijn voor andere gebruikers. Berichten en discussielijnen zouden verschillende statussen hebben, zoals:wachten op goedkeuring, goedgekeurd, gerapporteerd als spam, geblokkeerd. Voor de status van discussies en berichten zal ik een flexibelere manier kiezen om met statussen om te gaan door te linken naar de status
tafel. Dan moet de toepassing weten wat elke waarde betekent in de statustabellen (indien status ="GOEDGEKEURD", wordt de thread weergegeven), maar ik geef er de voorkeur aan dat dit gewoon een tekst opslaat in de thread
en post
tafels. We hebben een aantal statussen, zoals 'WAITING_FOR_APPROVAL', 'GOEDGEKEURD', 'REJECTED', 'REPORTED_AS_SPAM' en 'BLOCKED', en misschien willen we er in de toekomst meer toevoegen.
Met andere woorden, een gebruiker maakt een nieuwe thread of een nieuw bericht aan en krijgt de status "NOT_APPROVED". Niet-goedgekeurde discussielijnen en berichten worden niet getoond aan de meeste gebruikers; moderators kunnen echter niet-goedgekeurde items bekijken en kiezen voor "Goedkeuren" of "Weigeren". Gebruikers kunnen een thread of bericht markeren als spam, maar dat moet worden bevestigd door een moderator. Spamthreads en berichten worden niet weergegeven aan gebruikers.
Hierdoor kan ik de status
tabel voor zowel threads als posts, aangezien de statussen voor beide dezelfde betekenis moeten hebben. Ik zal de status
tabel om de status van gebruikers aan te geven; Ik denk niet dat dat een goede ontwerpkeuze zou zijn.
Formeel ontwerp
Dus breiden we de ERD uit die in deel 1 is gemaakt. Ik heb de tabellen die in het artikel van deel 1 zijn gemaakt geel gekleurd en de nieuw toegevoegde tabellen oranje gekleurd zodat het gemakkelijker is om de toevoegingen te zien. Ik heb echter geen individuele wijzigingen binnen tabellen gemarkeerd.
Wat nu?
Nogmaals, er zijn nog steeds aanvullende verbeteringen die moeten worden aangebracht, maar hier hebben we een heel eenvoudig online forum genomen en verschillende handige nieuwe functies toegevoegd.
In de volgende delen zal ik kijken naar het toevoegen van andere functies, zoals:
- forum categorieën en subcategorieën waarbij elke categorie een onderwerp heeft, verschillende moderators en aanvullende informatie zoals de aanmaakdatum van de categorie. Een onderwerp voor een post naast de inhoud
- en dan willen we gebruikers misschien toestaan om op discussies en berichten te stemmen en te stemmen.
Welke functies heeft uw online forum nodig? Zijn er functies waarmee ik rekening moet houden bij het voorbereiden van het volgende deel van deze serie? Als dat zo is, laat het me dan weten.
« Vorig deel | Volgend deel » |