Voilà , j'ai déjà remarqué quelques lacunes dans les non-lus. Voici une petite idée qui devrait fonctionner à la perfection sans pour autant trop charger la base (quoi que).

Création d'une nouvelle table "non-lu" qui contiendrait les informations suivantes:
- id du membre
- id du sujet
- id du dernier message lu dans le sujet

Il n'y a rien à faire lors du poste des messages, par contre dès qu'un membre lit un sujet il faut mettre à jour cette nouvelle table. La recherche des non-lus est relativement simple.

De ce fait il est possible de retrouver tous les messages non-lus pour un sujet et un membre donné, ce qui permettrait d'avoir cette information dans sujet.php lors de la lecture des messages. Et en plus ça devrait sésoudre tous les problèmes qu'il y a actuellement avec les cookies et la date de dernière visite.

Petit défaut: il est difficile de faire cela dans un mod car les changements touchent beaucoup d'endroit et de ce fait les autres mods risquent d'avoir des problèmes. Si nécessaire je peux toujours essayer de faire un mod pour tester cela ;-)

Hum c'est pas con de passer par la base de donnée en effet !
Par contre j'ai plusieurs questions :
1) Sachant que le système peut être résolu via les cookies (car actuellement je pense l'avoir codé et si phpBB marche avec les cookies ya pas de raison que FSB marche pas sans) est ce que ca vaut le coup de passer par la abse de donnée ?
2) Ca ne risque pas d'être lourd ? Ca risque de faire une requète en plus sur l'index et les forums (avec un peu de chance on peut éviter la requète en faisant une jointure) et un update de plus sur chaque sujet ?

L'update n'a lieu que lorsque le membre lit un sujet... et oui ça fait une requête de plus à ce moment vu qu'actuellement c'est juste le cookie qui est mis à jour. Par contre l'option cookie fonction pas du tout lorsque l'utilisateur se connecte depuis plusieurs machines, ce qui est mon cas par exemple.

Pour ma part la charge entre le client et le serveur (via cookie) ou entre le serveur et la base c'est pas bien différent en soit. Surtout que la requête est très simple.

Aussi avec les cookies, quand on arrive sur le forum et que l'on ne lis pas tout les messages, quand on revient les messages non-lu ont été consideré comme lu. C'est tres genant quand on passe rapidement sur le forum.

Si tu es certain que passer par la base de donnée pour les messages lus et non lus est la meilleure solution (ou du moins une solution équivalente aux cookie) je veux bien l'implémenter pour la prochaine release.

Le gros défaut c'est la taille de la table qui (si on ne concidère pas les utilisateurs morts) de: nombre d'utilisateur * nombre de sujet. Et cette taille ne variera que par l'ajout de sujet ou de membre forcément :P

De plus une entrée de la table est assez légère vu qu'elle ne contient que 3 ID. Par contre les fonctions: marquer le forum comme lu / marquer tous les forums comme lus seront un peu plus lente qu'actuellement. C'est là que la performence ce fera le plus sentir, et encore.

Et le problème que fabogranqi à mentionné serait automatiquement corrigé ;-)

Ouep mais en fait je vois un problème majeur que tu pointes toi aussi : la taille de la table.

Parce que si le but c'est d'enregistré tous les messages vus par tous les membres ... Ca risque de faire beaucoup d'entrées. Il faudrait par exemple vider toutes les entrées inutilisées de cette table au bout d'un certain temps je pense, par exemple on enregistre en plus a chaque fois la date de derniere visite du membre dans la table et on delete tout ca lors de sa connexion au forum.

Tu en penses quoi ?

Globalement comment voit tu le shéma de tout ca ?

non non, tu n'y es pas! on stock juste l'ID du dernier message de chaque sujet lu par le posteur. La taille de la table ne va pas exploser ça c'est sà»r (à moins que tu ais des milliers et des milliers de sujets et idem pour les membres, et encore les messages prendront bien plus de place).

Ayant le dernier message d'un topic lu par le posteur concerné, on peut en déduire que tous les suivants sont non-lus... et ainsi ajouté une information précise dans la page sujet.php en indiquant tous les messages non-lu. On pourrait aussi ajouter un lien sur le premier message non-lu à la place (ou en plus) du dernier message ;-)

De plus quand le posteur lit le sujet, on ajoute pas une entrée dans la base (à moins qu'il n'y en ait pas pour ce posteur là sur ce sujet-ci) mais on met juste à jour l'ID du dernier message lu... C'est très simple et c'est la solution qui garanti le moins de problème tout en étant pas trop lourde (voir même assez légère) pour la base.

Eagle, qui n'a pas l'habitude de travailler avec des bases contenant si peut de données :P

Alala je suis embrouillé, désolé mais j'ai pas tout suivi, je suis sur que ta solution est super mais je n'ai plus suivi. Tu peux me décrire étape par étape ce qui se passe ? On enregistre un seul message par personne ?

Genova un peu perdu

Reprennons donc depuis le début...
Lorsque quelqu'un poste un message ou un nouveau sujet, son entrée à lui (ID membre) pour le sujet est mise à jour avec l'ID du message posté (ou ajoutée si elle n'existait pas encore).
Lorsque un membre se connecte on relève grace à cette table tous les sujets qui ont eu des nouveaux messages (dont le dernier message ID n'est pas le même que le message ID de la nouvelle table ou qu'il n'y a pas d'entrée dans cette table pour lui - sujet jamais lu). Lorsque le membre a lu le sujet on met à jour la nouvelle table comme lors du poste pour le posteur.

Finalement la table contient pour chaque membre la liste des sujets avec le dernier message lu par ledit membre.

J'ai un peu de peine à être plus clair je suis désolé...

Ok c'est déjà plus clair, donc si je comprend on aura une table avec comme champs :


(J'ai rajouté sujet_id et forum_id, il les faut non ?)

Ensuite lorsqu'un membre poste un message / nouveau sujet, on ajoute dans la table l'ID du posteur et du message (+sujet et forum).

Par contre tu peux me faire une ébauche de requète pour récupérer les messages non lu ?

forum_id n'est pas indispensable mais pourquoi pas... sujet_id est effectivement indispensable oui c'est l'une des trois colonnes vitales ;-)



Et là on devrait avoir les messages non-lus pour le membre concerné sur le forum donné...
Maintenant cela présupose que les message_id sont donnés de manière incrémentale, mais il me semble que ce soit le cas.

Ah oui mais je vois, mais il y a un petit détail :
admettons il s'agit d'un nouveau sujet, donc on a dans la table_lien actuellement l'ID du posteur du sujet, l'ID du message et du sujet. Mais il n y a actuellement pas les IDS des autres membres, ta requète marchera tout de même ?

Bon, là il manque les jointures... c'est un oubli de ma part...

Ensuite je vois pas comment traiter le cas d'un nouveau sujet sans une requête supplémentaire comme suit:



Bon, il faut bien évidemment étudier tous les cas mais il y a des solutions pour chacun. C'est juste pas évident de sortie toutes les requêtes comme ça, de tête...

Ouai ca risque d'être un peu plus compliqué que prévu, mais je tenterai ne t'en fait pas, si tu as des idées ou des trucs pour ml'aider à avancer hésites pas à poster