compteur de lecture [structure optimale bdd]

[jer666]

Bonsoir

je dois realiser un compteur des visites de mes articles en php.

Les articles les plus lu seront recompensés.

De ce fait je dois creer un systeme de visite qui ne compte qu'une fois chaque visiteurs afin de ne pas avoir trop de triche.

De plus je desirerais faire ressortir l'article le plus de la veille ainsi que de la semaine passée.

donc je pense que la maniere optimale de creer ma bdd est de creer

1 base articles avec l'id de l'article...

1 base visiteurs en enregistrant une id pour chaque visiteurs et une ip

1 basevisite_par_article avec un champs id 1 champs id_video 1 champs id_visiteur et un champs date.

malgré cela, ayant entre 3000 et 5000 visiteurs par jours, je pense que ma bdd va exploser. comptons 5000 visiteurs en moyenne pour voir large. sur 30 jours ca fait 150 000 entré. (5000*30) et donc 1 750 000 entrée sur l'année.

de quoi avoir une bdd d'1go dans quelques années

si vous aviez une idée pour améliorer tout cela? merci par avance ! tout est bon a prendre

[gvosnet]

Et si tu mettais un champs date de dernière connexion dans ta table visiteur.

Et un champs nbre_visites dans ta table articles.

Pour une IP spécifique (un visiteur donc), tu vérifies si ça dernière connexion a eu lieu ce jour ou pas. Si oui, tu n'incrémente pas le compteur nbre_visites. Si non, tu incrémentes nbre_visites (tout en mettant à jour la date de connexion de ton visiteur).

Du coup, t'as aucune table de correspondance, et donc ta base reste raisonnable.

(bon, c'est qu'une idée comme ça...y'a peut-être une meilleure méthode)

[Mandor]

Si tu te mets à enregistrer les IPs de tous tes visiteurs pour chaque article, avec tous les bots qui trainent ta base va exploser c'est certain.

Ta meilleure option est donc d'utiliser des sessions:

- Pour chaque visiteur, tu ouvres une session.

- Dans les données de cette session, tu crées un tableau contenant les IDs des articles visités par l'utilisateur.

- Incrémente le compteur uniquement si l'utilisateur visite un article dont l'ID ne figure pas dans le tableau des articles déjà visités et rajoute l'ID au tableau.

Ensuite se pose le problème de la persistance des sessions...

Si tu ne veux pas que le compteur s'incrémente quand un utilisateur visite un article, ferme son navigateur et revisite l'article, il faut utiliser des cookies :

- Crée un cookie contenant la session_id de l'utilisateur.

- Enregistre dans une table SQL la session_id et la table des IDs sérialisée qui correspond.

Voilà comment ça marche ensuite:

1) Quand un utilisateur visite une page, commence par vérifier s'il a une session d'ouverte.

---> Si oui, tout va bien, pour chaque article visité il suffit de vérifier si l'ID est dans le tableau pour savoir si on incrémente ou non.

---> Si non, étape 2).

2) L'utilisateur n'a pas de session d'ouverte, on vérifie s'il a un cookie avec une session_id.

---> Si oui, l'utilisateur est déjà venu, il suffit de récupérer les information de sa session dans la base de données et de la restaurer puis retour à l'étape 1).

---> Si non, soit l'utilisateur n'est jamais venu, soit il a effacé ses cookies: dans les deux cas il faut démarrer une session neuve avec un tableau d'IDs vierge.

De cette façon, la charge pour la base de données est minimale: elle ne sert qu'à restaurer la session d'un visiteur qui revient sur le site après avoir fermé son navigateur et contiendra au pire un enregistrement par visiteur. Pour en limiter la taille, tu peux rajouter dans la table des session_id une date de dernière utilisation de cette session et purger régulièrement celles qui sont, par exemple, inutilisées depuis plus d'une semaine (on "oublie" les visiteurs qui ne reviennent pas).

Note que même un utilisateur qui rejetterait les cookies ne pourrait pas faire monter le compteur d'un article simplement en rechargeant la page: il lui faudrait fermer et rouvrir son navigateur à chaque fois pour réinitialiser la session (et sans cookies, ce système lui créera une nouvelle session au lieu de restaurer une ancienne). Tu peux eviter ça en rajoutant l'IP des visiteurs dans la table des session_id et, en cas d'absence de cookie, vérifier si l'IP est "connue".

Après si l'utilisateur efface ses cookies et change d'IP, il n'y a plus rien à faire à part imposer aux visiteurs de s'enregistrer.

Voilà en tout cas, exposé de façon rapide, la méthode habituellement utilisée pour régler ton problème sans surcharger la base.

[jer666]

excelent!!!! merci beaucoup! c'est vrai que je n'avais pas pensé a utiliser les session je vais lancher sur le probleme en me basant sur tes recommandations! merci beaucoup!!

et merci gvos_net pour ta remarque

[The Lootrophile]

et donc 1 750 000 entrée sur l'année.

de quoi avoir une bdd d'1go dans quelques années

Pense à google qui indexe plus de 24 000 000 000 de pages.

Sinon, +1 au dessus, la session est ta meilleure amie. =)