Dans mon premier article sur un forum en ligne, j'ai mentionné qu'il pourrait y avoir plusieurs fonctionnalités plus avancées à ajouter :
- Plus de détails formels sur l'utilisateur au lieu d'un seul champ "nom". Vous voudrez peut-être le prénom, le nom et le nom d'utilisateur ou le surnom de l'utilisateur. Un forum agréable permettrait également aux utilisateurs d'avoir une photo de profil, un e-mail, des rôles, un statut (pour permettre aux utilisateurs d'être bloqués) et d'autres informations comme la dernière fois qu'ils ont visité le forum.
- Contrôle supplémentaire lié à la création d'utilisateurs afin que nous puissions savoir quand un nouvel utilisateur est créé mais avant que son adresse e-mail ait été confirmée.
- Forum catégories et des sous-catégories où chaque catégorie a un sujet, plusieurs modérateurs et des informations supplémentaires comme la date de création de la catégorie. Un sujet pour un article en plus du contenu
- Messages modérés qui doivent être approuvés par un modérateur avant d'être visibles par les autres utilisateurs. Les messages et les fils de discussion auraient des statuts différents :en attente de publication, publié, signalé comme spam, bloqué, débloqué.
- Ensuite, nous voudrons peut-être autoriser les utilisateurs à voter pour et voter contre fils de discussion et messages.
Pour le forum, j'utiliserai le terme "thread" pour faire référence à une conversation avec potentiellement plusieurs messages liés au thread.
Je ferai un commentaire d'ouverture; J'utilise généralement des nombres ronds comme 100 ou 1000 pour définir la longueur des champs varchar; Je ne suggère pas que ce sont nécessairement la taille appropriée, mais je l'utilise comme raccourci, plutôt que de laisser la longueur indéfinie (%). D'un autre côté, j'utilise parfois des longueurs très spécifiques pour des champs comme email et ip_address; 254 est la longueur maximale qu'une adresse e-mail peut avoir selon les définitions RFC, tandis que 45 est la longueur maximale qu'une adresse IPv6 peut avoir.
Détails de l'utilisateur
Dans la première partie de notre série d'articles sur la création du forum en ligne, les informations sur les utilisateurs étaient très limitées. Je vais améliorer les détails de l'utilisateur qui sont stockés. Pour l'instant, la modération sera très basique :les utilisateurs seront modérateurs ou non. Nous pourrions créer des règles de modération plus compliquées liées aux catégories et aux discussions plus tard.
Pour le statut des utilisateurs, je vais créer le user_status table, afin que je puisse la réutiliser dans une autre situation même s'il y a très peu de statuts, comme "EMAIL_NOT_VERIFIED", "VERIFIED" et "BLOCKED".
Création d'utilisateur
J'utiliserai le statut de l'utilisateur pour reconnaître les utilisateurs qui ont le statut "EMAIL_NOT_VERIFIED" après qu'un utilisateur a créé son compte et qu'un e-mail a été envoyé à son adresse e-mail donnée, mais avant qu'il ait cliqué sur l'URL de vérification dans l'e-mail. Vous pourriez même devenir plus délicat et avoir des statuts comme "EMAIL_VERIFICATION_TO_BE_SENT" et "EMAIL_VERIFICATION_RESENT" si certaines de ces étapes sont gérées par différents composants de votre système et pas immédiatement lors de la création de l'utilisateur.
États des fils de discussion et des publications
Les messages modérés doivent être approuvés par un modérateur avant d'être visibles par les autres utilisateurs. Les messages et les fils de discussion auraient des statuts différents, tels que :en attente d'approbation, approuvé, signalé comme spam, bloqué. Pour le statut des fils de discussion et des messages, je choisirai une manière plus flexible de gérer les statuts en créant un lien vers le status table. Ensuite, l'application doit savoir ce que signifie chaque valeur dans les tables d'état (si status ="APPROUVÉ", le fil est affiché), mais je préfère cela au simple stockage d'un texte dans le thread et post les tables. Nous aurons quelques statuts, comme "WAITING_FOR_APPROVAL", "APPROVED", "REJECTED", "REPORTED_AS_SPAM" et "BLOCKED", et nous voudrons peut-être en ajouter d'autres à l'avenir.
En d'autres termes, un utilisateur crée un nouveau fil ou un nouveau message, et il est mis dans le statut "NOT_APPROVED". Les discussions et les messages non approuvés ne sont pas affichés pour la plupart des utilisateurs ; cependant, les modérateurs peuvent afficher les éléments non approuvés et choisir "Approuver" ou "Rejeter". Les utilisateurs peuvent marquer un fil ou une publication comme spam, mais cela doit être confirmé par un modérateur. Les fils de discussion et les messages de spam ne sont pas affichés aux utilisateurs.
Cela me permet d'utiliser le status table pour les fils de discussion et les messages, car les statuts de ceux-ci doivent avoir la même signification. Je n'abuserai pas du status tableau pour indiquer le statut des utilisateurs ; Je ne pense pas que ce serait un bon choix de conception.
Conception formelle
Nous étendons donc l'ERD qui a été créé dans la partie 1. J'ai coloré les tableaux qui ont été créés dans l'article de la partie 1 en jaune et coloré les tableaux nouvellement ajoutés en orange afin qu'il soit plus facile de voir les ajouts. Cependant, je n'ai pas marqué les modifications individuelles dans les tableaux.
Et ensuite ?
Encore une fois, il reste encore des améliorations à apporter, mais ici, nous avons pris un forum en ligne très simple et ajouté plusieurs nouvelles fonctionnalités utiles.
Dans les parties suivantes, j'examinerai l'ajout d'autres fonctionnalités telles que :
- catégories de forum et des sous-catégories où chaque catégorie a un sujet, plusieurs modérateurs et des informations supplémentaires comme la date de création de la catégorie. Un sujet pour un post en plus du contenu
- puis nous pourrions autoriser les utilisateurs à voter pour et contre les fils de discussion et les messages.
De quelles fonctionnalités votre forum en ligne a-t-il besoin ? Y a-t-il des fonctionnalités que vous voudriez que je prenne en compte lors de la préparation de la prochaine partie de cette série ? Si oui, faites-le moi savoir.
| « Partie précédente | Partie suivante » |
