Algo pour gérer les status lu / non lu sur un forum

Par Pakito, il y a 12 ans

Les bases Algorithmique

Bonjour à tous,

Je planche depuis un moment sur un gros forum pour l'un de mes projets. N'ayant rien trouvé dans les librairies gratuites et voulant un contrôle total sur le code et sur les vues, j'ai choisi de le coder moi-même.

C'est donc développé sous Cake PHP, et tout fonctionne bien. Cependant j'en arrive aux finitions : la partie post / edit / quote, qui est une question de temps, et la partie read / unread.

Cette dernière me poste quelques soucis : compte tenu de la structure complexe du forum et du nombre d'utilisateurs qu'il va recevoir (la base d'utilisateur potentielle du site étant de 5M d'utilisateurs), j'essaie de trouver un algo qui soit optimisée au mieux :

A noter que je souhaite stocker ces liaisons en BDD pour plusieurs raisons :

La structure du forum est la suivante :

La première idée qui me vient, c'est de faire des tables de liaisons :

Dans les faits je me dis tout d'abord que les Replies, ça va surcharger complètement le système. Donc ça, c'est à éviter.

Pour les Topics, ça devient un peu plus clair : l'utilisateur lit le topic, on passe la liaison à read.
Cependant, il y a plusieurs interrogations quant au passage à read :

Pour les ForumsCategories, c'est un peu plus facile : si tous les topics sont read, alors la ForumsCategory est read également.
Mais les questions se posent alors sur la façon de faire :

L'une comme l'autre des solutions génèrent forcément beaucoup de requêtes. J'ai tendance à penser qu'en général, un traitement beforeSave est préférable à un traitement beforeFilter, les SELECT étant souvent plus nombreux et nécessitant moins de ressources que les INSERT ou UPDATE, mais en l’occurrence, je risque d'avoir énormément de réponses postées, alors que je pourrais ne générer de requête qu'à l'affichage de la vue par l'utilisateur.

N'ayant que peu de retour d'expérience là dessus (j'ai un peu fouillé PunBB et PHPBB il y a quelques années de cela, mais rien de plus), j'ai tendance à pensé qu'il n'existe pas vraiment de bonnes pratiques en la matière, c'est pourquoi je me tourne vers vous avant de me lancer dans une architecture complexe qui pourrait s'avérer bien trop gourmande.

Merci d'avance pour vos réactions et commentaires constructifs.

2 réponses

nestecha, il y a 11 ans

Oui non, repliesReadByUsers est clairement inutile.

Pour ta question, tu sais où se situent les dernières réponses dans un topic, puisque tu as le nombre de réponses totales qu'il y a, tu as une pagination, donc tu as tout ce qu'il faut.

Si l'utilisateur n'est pas sur la dernière page > le topic reste unread quoi qu'il arrive.
Si l'utilisateur est sur la dernière page > le topic devient read.

Ensuite, si quelqu'un ré-écrit derrière, alors le topic devient unread pour TOUS.

Et cette dernière fonction va overwrite toutes les autres, puisqu'elle se fera forcément en dernier.

Donc si l'utilisateur rafraichit sa page mais qu'il n'est plus sur la dernière page, le topic est unread, s'il est toujours sur la dernière page, le topic est read, s'il retourne à l'index des topics, il sera unread.

Pour l'UX, c'est comme pour tout, il faut un équilibre.

Tu ne peux pas avoir une UX absolument parfaite sur un forum sans avoir un serveur qui en prend plein la poire. C'est pour ça que tu vois ta catégories de topic qui est inscrite comme non lue, et non pas une icône avec un nombre de topic non lu intra catégorie. La différence de requête est monstrueuse à grande échelle. Donc faut faire des choix de ce côté là.