salut à tous,

Avec mon confrère Alp, nous codons un forum.

Seulement voilà, quelqu'un (on ne dira pas qui, mais pas moi ) a créé une table contenant l'id du visiteur (identifié) et l'id du post en question pour determiner s'il l'a vu ou non.

Ceci étant un peu bourrin, je pensait à la chose suivante :

Ajouter un champs "lu par", mais bon, où : dans la table sujet (on a une table sujet), ou dans le profil du membre? Et donc ensuite faire un test de la présence de l'id du visiteur dans ledit champ... (les id étant séparés par des virgules par exemple)

Sauf que cela ne me parait guerre mieux... et lent pour... pas grand chose? Bon, si en fait, mais je ne me rends pas compte des ressources nécéssaires pour cela.

Par contre, si ce systeme est mis en place, il est evident que des "LIMIT" vont être mis en place. Oui mais, à combien ?

Merci d'avance !

J'ai conseillé la méthode de la table dédiée à Alp, pour la simple raison que cela demande bien moins de ressources qu'un ereg pour vérifier la présence de l'id dans une chaine (je ne comprend pas pourquoi tu qualifie cette méthode de bourrine).

MySQL peux être optimisé en fonction de cette utilisation, mais pas avec la méthode d'un champ contenant les ID collés.

Dans ce cas je présente mes plus plates excuses a Alpounet

A coté de ça, imaginons (oui je grossis expres) une centaine de membres, et un milliers de posts, on arrive déjà a 10'000 enregistrements ...

Je ne connais pas les "limites" de mysql en matiere de traitement de tant d'enregistrements, mais ça m'a quand meme paru conséquant.

D'où la nécéssité de bien contruire cette table, les champs doivent être des entiers, avec le même nombre de numéros que pour les champs membres.id et post.id

Si cela est fait ainsi, MySQL optimisera, et 10000 enregistrement ne seront pas de trop.

Ceci dit il sera toujours possible d'optimiser en supprimant les lignes qui font référence aux posts plus anciens que ceux visibles sur les deux ou trois premières pages, et d'afficher ces même post automatiquement comme 'lu'.

D'aprés moi c'est franchement lourd oui, et si j'étais vous je remplacerai plutot cette idée par une indication des "nouveaux sujets" en stockant la date de dernier login du membre et en la comparant à la date de post des sujets.

Oui mais faut aussi pouvoir traiter les réponses aux sujets : une ptite image mise en évidence dans le cas ou qqn a répondu sur un sujet qu'on avait consulté AVANT LA REPONSE ...

Enfin c'est vraiment le truc chiant à faire, car plusieurs manières mais on ne sait pas quelle est la bonne ...
Au pire on code les 2 3 manières qu'on connait, et on fait des scripts de test? ^^

aplusse

Ps : [Dans ce cas je présente mes plus plates excuses a Alpounet] <<< merci bien maraud

Rah mon navigateur vient de planter, j'ai vraiment un os pourrit, plaignez moi.
</blog>
Solozerk> Déjà bonjour
L'idée de la date, nous l'avons eut, mais elle ne correspond pas exactement à ce que nous recherchons : on ne veut pas du "potentiellement" lu ( ou plutot nouveau poste ) mais un lu : oui / non.
Et là, la methode des dates ne marche pas.

A ce que je sache, la méthode la plus simple serait une date couplée avec un cookie pour la session en cours. Le cookie contient les messages lus dans "cette session", lorsque l'utilisateur quitte le site, (enfin à son retour) sa date de dernière lecture est remise à jour.

Enfin bon, ça reste peu sûr, mais il faut bien savoir que ça n'a jamais été une fonction précise et essentielle.

Oui, mais cela reste bien pratique

D'autres propositions?

D'une manière ou d'une autre, Alp, si tu veux un système fiable, qui s'applique à tous les posts pour tous les utilisateurs, cela fait une grande quantité d'informations.

Et le seul moyen de l'éviter est de perdre en fiabilité.

Si ton choix est donc que le système soit précis, alors autant bien ordonner ces données plutot que de bidouiller en consomant autant de ressources, sinon plus.