Nombre de fois que le sujet a été vu

On incremente juste un champs "vu" à chaque chargement de la page ^^
Donc oui si un membre fait F5, c'est comme si 2 membre avait visité la page.

Sinon non, on ne passe jamais par les ip. De 1 car celles ci sont variable, de 2 car ca serait trop compliqué. Il faudrait les séparer par une virgule, puis les explode pour vérifier ensuite.
Puis un sujet à 1500 vue, les 1500 ip prenne de la place.

A la limite on peut prendre l'id du membre ^^

Mais bon, pourquoi s'embêter?
Je n'ai jusqu'à présent vu aucun forum s'embêter ainsi :P

ça ne m'aide pas beaucoup, mais merci d'avoir essayer :)

Grafikart m'avait dit il faut le faire avec un

UPDATE

Mais moi aussi j'ai pas trop compri donc faut chercher :p

En gros, dans chaque page php d'un sujet tu as un requete de la sorte :

UPDATE sujet SET vu = vu + 1

Voila :

$sql ="UPDATE table SET ici le nom de ta colone = ici le nom de ta colone + 1";
$req = mysql_query($sql) or die ('Erreur SQL');

bien sur apprêt sa mais + 1 pour tout les sujet donc apprêt faut tu face en sort qui sais quel sujet prend mais pas tout

Je vois ce qu'il veut faire. La requête SQL efectivement , c'est ça.
Je pense car par qu'il clique dessus. Mais après c'est vrai ça devient lent.
A part ça je vois pas comment faire ça sans se compliquer la vie.
Enfin la plupart des forums que j'ai vu sont comme ça.

C'est faisable, mais tu va devoir, créer un nouveau champ dans ta bdd en plus de champ qui contient le nombre de visite, utiliser une expression régulière et faire en sorte que le visiteur est une id unique stocké dans un cookie.
Si le visiteur ne supporte pas les cookies tu ne compte pas de visite.

Bien-sur même avec un tel système si le visiteur supprime les cookie, ça génère forcément une nouvelle visite.

Après si c'est un forum avec beaucoup de visite, tu a inféré d'avoir un serveur qui assure.

Stocker l'ip n'est pas un très bon choix, en plus avec l'ipV6 qui débarque et qui est stocké sur 39 caractères je crois, ça risque vite de prendre de la place :)

Personnellement, je stocke l'id de l'article dans une variable tableau de session, avec les 10 derniers articles d'enregistrer, s'il visite un onzième, je rajoute l'id, je supprime via un unset le première enregistrement (le plus ancien) et je réorganise les clés via un array_slice qui renumérote les clés. J'ai juste a faire le test if(in_array('id_demander',$_SESSION'id_déjà_vue'])). Ca permet d’incrémenter proprement les articles et de ne re-incrémenter pour la même personne que si elle a déjà vue 10 autre articles.

Sa change pas sauf que là on pert pas en performanc emais en place. Je pense qu'un serveur web, enfin cela dépend coment c'est héberger, l'éxécution d'un update coute moins cher et puis sa change pas des masses. Je pense que sur tout les processus qu'on a citer il y a pas de changement de performance.
Par contre faire de la base de donnée et utiliser un cookies c'est la même chose , on stocke l'information.
Et puis dans tous les cas c'est le serveur qui le gère.
Doncc faire une vérification qui semble faire une verification ce qu'on a regarder ça sert pas trop je pense. surtout qu'on éteint le navigateur, la sesssion s'efface ou quand on change de navigateur on a pas la même session. Autant incrementer quand on va dessus.

9 mois plus tard... pourquoi ne pas mettre en place un Trigger Mysql qui ferait l'update à chaque select du post ?