Bah disons que les codes seront probablement très différents, donc c'est soit l'un soit l'autre mais ça ne peut pas être les deux

vben pk pas les deux avec un syteme de désactivation non?
mais sinon je serait pour la version avec base de données.... en limitant à x enregistrement même si c'est plus lourd ca évitera des pertes....

Il me sufira de rajouter un champs dans le db maintenance que je code pour la prochaine release de FSB, qui supprimera les champs obsolètes de la table des messages nons lus.

Pourquoi faire l'un ou l'autre ? Car suivant la méthode les tableaux seront différents et ca va être difficilement exploitable.

Bon, dans mes modifications j'ai essentiellement changé la fonction recuperer_nouveaux_message() et j'ai ajouter des fonctions pour marquer comme lu les sujets dans plusieurs cas.

Maintenant il reste à faire:
- gestion des droits pour les non-lus aussi (ignorer les sujets dans les forums o๠le membre n'a pas le droit d'accès)
- affichage pour chaque message (dans sujet.php) d'un icone s'il est non-lu
- vérifier que tout fonctionne bien
- optimiser certaines requêtes
- ajouter une liste des sujets non-lu disponible depuis l'index
- vérifier que tout fonctionne bien
- et... vérifier que tout fonctionne bien :P

Et je vais mettre ma version en ligne se soir en m'arrangeant avec DDril ou Mido pour un hébergement temporaire comme cela tout le monde pourra tanter de faire planter cette version "demo" ;-)

Ok c'est cool, si je peux je te test ca ce soir (enfin si je suis la vu que je risque de sortir). Sinon je regarde demain.

Voilà le lien vers : Non-lu dans la base

Et il y a les deux mods que j'ai fait qui sont également installé...

Super, mais, quand j'ai lu message il reste 'non lu' (pour un visiteur)

En effet... il devrait jamais être non-lu pour un visiteur, c'est une erreur de ma part... je vais corriger ça...

ou ca marche au poil
si je peux me permettre une suggestion
faire de même au niveau de la liste des forum, cela peut être utile si il y a pas mal de forum

Donc tu as fait tes tests eagle ? Ca marche parfaitement pour le moment ?

Oui, les tests sont en cours... alors vous pouvez venir nombreux et poster n'importe quoi juste pour que je puisse vérifier que tout fonctionne... et si vous remarquez un proplème n'hésitez pas à poster ici ^^

Bon... je me réponds à moi-même pour changer... que c'est pas bien!

Voilà , la version qui est toujours disponible là a été améliorée. En voici l'état:

- recherche des non-lus: 2 requêtes SQL à la place d'une seule.
- lecture d'un sujet: 1 requête SQL si (et seulement si) le sujet avait des messages non-lus à la place d'aucune
- marquer comme lu (forum ou tout): 1 requête par sujet à marquer comme lu en plus, c'est là o๠la charge sur la base est vraiment augmentée.
- inscription d'un nouveau membre: fait un marquer comme lu...

Note: j'ai ajouté la recherche des non-lus lors de l'inscription et dans sujet.php pour le premier ça change presque rien et pour l'autre ce sera de toute façon utile pour marquer chaque message non-lu comme non-lu.

C'est la fin du petit topo sur la charge de la base de données avec ce système de non-lu. Maintenant à vous de tester et voir s'il y a encore des erreurs et à toi Genova de voir si c'est utilisable pour une future version de FSB ou si tu préfères t'en tenir aux cookies.

Eagle,

Je vais surement utiliser ton système, est ce que tu pourrais me faire un listing des modifications stp ? Désolé de ne pouvoir tester ca soir (je suis avec ma copine et demain j'ai une lan donc ca va être dur) mais demain soir si je peux ou bien dimanche

Merci en tout cas pour ton investissement

Eagle, le nombre d'entrée maximale avec ce script est donné par nb_de_membre * nb_de_sujet.
Sur un forum avec 1000 membres et 10 000 sujets ca fait 10 000 000 d'entrées, c'est beaucoup quand même ^^ Il doit y avoir moyen d'optimiser non ? J'ai pensé que je pourrais peut être comparé la date du dernier message d'un sujet (en rajoutant un champs ds la table messages_lus) avec la date d'inscription d'un membre, ce qui élimerait pas mal d'entrées déjà (notamenet sur les topics qui tombent aux oubliettes et que actuellement le système de messages non lus ajoute ds la table, alors que caz pourrait être évité pour les membres qui se sont inscrit après que le topic soit passé aux oubliettes). Tu en penses quoi ?

par contre je pense que se serrit miux de fiare une table genre avec id_user et unread et dans unread de type text faire un e chaine spéarer par des , qque par après on remet en tableau....

mais de totue manièreje pense que le mieux se serait de faire un truc genre via des cookies lors de la conection on prend les message non lu et on els affiche et on le garde dans un cookies ce qui éviterai de devoir recalculer à chaque page les mesage non lu non?

On pourrait en effet mixer la base avec les cookies... du style pour une session données on va chercher les non-lus une fois et c'est tout... sauf qu'après il faut traiter les nouveaux messages et ça c'est pas évident...
La solution des cookies doit être révisée à chaque changement de session (changement de machine,...) car sinon elle fonctionnera jamais correctement.

Pour la base, c'est vrai que ça fait beaucoup de ligne. Et je suis d'accord pour ton option d'optimisation Genova, c'est une idée mais il faudra alors changer la requête pour que ces sujets obsoletes soient marqués comme lus sans avoir d'entrée dans la nouvelle table. En même temps pour l'instant les membres "morts" ne génère aucune ligne dans la base... seul un membre qui se connecte et qui marque tout comme lu va remplir cette base, comme moi ce matin.

Bon, j'ai remarqué un net ralentissement dans l'accès à ce forum, il y a donc des amélioration à apporter. Je vais y réfléchir mais c'est bien d'avoir un exemple sur un forum déjà chargé, même si les utilisateurs (dont je fais partie) vont légèrement en patir niveau performence... Un premier point: il n'y a pas de clé primaire dans la table fsb_lus il en faudrait une (peut-être).