Discussion :

[MaTHieU_]

Bonjour,

Je souhaite réaliser un petit script de statistiques en PHP/MySQL pour mon prochain site. Je souhaite entre autre pouvoir faire une requête qui affiche le nombre de personnes actuellement connectées (à 1 ou 2 minutes près).

Mon problème, je ne sais pas trop quelle architecture de table je dois mettre en place en sachant que je dois détecter si le visiteur est déjà passé sur le site le jour même, vérifier l'adresse IP, éventuellement tester un cookie, utiliser les sessions. Je veux pouvoir savoir pour un visiteur quelles pages il a consultées sur le site, d'où il vient et quelle navigateur il utilise.

Je pense à une architecture comme la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
ID : int (autoincrement)
DATE : timestamp
IP : varchar(15)
HOST : varchar(255)
REFERER : varchar(255)
USER_AGENT : varchar(255)
PAGES : varchar(255)

Je vais essayer de l'améliorer via vos commentaires et conseils.

Merci d'avance,
Mathieu

[Biglo]

Salut,

Je n'ai pas énormément de conseils à te donner.

Pour l'adresse IP, je te conseille de la stocker en tant qu'entier. Ca prendra beaucoup moins de place et surtout un index sur cette colonne sera bien plus performant. MySQL propose les fonctions INET_NTOA() et INET_ATON() qui permettent de transformer une adresse IP en notation pointée sous forme numérique et inversement.

Il ne doit pas exister énormément de User_Agent. Peut-être pourrais-tu créer une table "UserAgent" et y stocker les principaux. Ainsi dans les infos du visiteur, tu pourrais y placer un TINYINT ou un SMALLINT, toujours dans l'esprit de gagner de la place.

Sous quelle forme penses-tu stocker le champ "Pages" ? Je vois que tu lui as donné le type "chaîne", mais je ne vois pas comment tu comptes l'utiliser.

Pourquoi un timestamp pour la date ? Que représente-t-il ? La date de la dernière visite (page demandée) ? J'aurais pensé que la date du jour t'aurait suffit (donc type DATE) et j'aurais mis une contraine d'unicité pour (IP, DATE).

Bien sûr, je ne saispas quelles informations te seront utiles. Par exemple, si un même visiteur vient sur la page "index" avec le referer "google". Mais un peu plus tard dans la journée, il est possible qu'il revienne avec un autre referer. Veux-tu garder les deux ?

Voilà, je pense qu'un peu plus de détails de ta part serait le bienvenu. Avec éventuellement une mise en situation et un petit jeu d'essai.

[MaTHieU_]

Bonjour,

Alors voici des détails comme demandé :

Pour l'adresse IP, je te conseille de la stocker en tant qu'entier.

En effet, je ne connaissais pas cette fonction

Il ne doit pas exister énormément de User_Agent.

Si justement, il en existe énormément, cette données, je souhaite la garder, c'est à partir d'elle que je vais déterminer le navigateur et l'OS.

Par exemple, si un même visiteur vient sur la page "index" avec le referer "google". Mais un peu plus tard dans la journée, il est possible qu'il revienne avec un autre referer. Veux-tu garder les deux ?

Oui, je souhaite garder les deux.

Avec éventuellement une mise en situation et un petit jeu d'essai.

Je vais donc essayer de donner un exemple :

• Première visite, on enregistre les informations du visiteur (sessid, ip, host, referer, useragent)
• Parcours du site, on enregistre les pages vues et le tempe entre chaques pages
• Deuxième visite, même jous, même IP ou cookie, on créé un nouvel enregistrement (en effet, la personne peut avoir changé de navigateur, utilisé un autre moyen pour arriver sur le site, etc.)

Ce qui est unique à un moment T :

• IP / HOST
• SESSID

Ce qui peut changer :

• REFERER
• USER_AGENT
• PAGE CONSULTEE

Il faut que je trouve une méthode pour détecter et regrouper les informations du visiteur qui vient plusieurs fois dans la même journée. Ce que l'on appelle "visite unique". Celle-ci ne peut se faire que par l'ip ou le cookie je pense.

J'attend vos commentaires pendant que je prépare une structure améliorée grâce à tes conseils.

Merci pour votre aide,
Mathieu

[Biglo]

Si justement, il en existe énormément, cette données, je souhaite la garder, c'est à partir d'elle que je vais déterminer le navigateur et l'OS.

En fait, ce que je propose, ça serait d'analyser le user agent et ne pas le stocker tel quel dans la table. On pourrait par exemple imaginer une table "navigateur" (mozilla, IE, firefox, opera, ...), une table système d'exploitation et dans ta table d'infos sur le visiteur, tu aurais deux clés étrangères pour l'OS et le navigateur + des champs pour la version par exemple.

Ca te permettrait de gagner déjà pas mal de places. Car si tu stockes l'user agent pour chaque visiteur, la taille va "exploser" sur les sites très fréquentés. Par exemple, si on compte une moyenne de 50 octets par user agent, et 10000 visiteurs par jour : tous les mois, ta table augmentera de 14Mo juste pour cette info.

J'insiste beaucoup sur la taille de la base, mais ça me semble réellement important pour ce genre d'applications.

Je vais donc essayer de donner un exemple :

• Première visite, on enregistre les informations du visiteur (sessid, ip, host, referer, useragent)
• Parcours du site, on enregistre les pages vues et le tempe entre chaques pages
• Deuxième visite, même jous, même IP ou cookie, on créé un nouvel enregistrement (en effet, la personne peut avoir changé de navigateur, utilisé un autre moyen pour arriver sur le site, etc.)

Comment comptes-tu distinguer une deuxième visite d'une visite qui se continue ? Session fermée = fin de visite ?

Il faut que je trouve une méthode pour détecter et regrouper les informations du visiteur qui vient plusieurs fois dans la même journée. Ce que l'on appelle "visite unique". Celle-ci ne peut se faire que par l'ip ou le cookie je pense.

Si ce n'est pas déjà fait, il faut également que tu penses au cas de plusieurs utilisateurs d'un même réseau qui visitent le site. Il risque donc d'y avoir plusieurs couples (sessId, ip) en même temps.

[MaTHieU_]

Bonjour,

En fait, ce que je propose, ça serait d'analyser le user agent et ne pas le stocker tel quel dans la table. On pourrait par exemple imaginer une table "navigateur" (mozilla, IE, firefox, opera, ...), une table système d'exploitation et dans ta table d'infos sur le visiteur, tu aurais deux clés étrangères pour l'OS et le navigateur + des champs pour la version par exemple. Ca te permettrait de gagner déjà pas mal de places. Car si tu stockes l'user agent pour chaque visiteur, la taille va "exploser" sur les sites très fréquentés. Par exemple, si on compte une moyenne de 50 octets par user agent, et 10000 visiteurs par jour : tous les mois, ta table augmentera de 14Mo juste pour cette info.

C'est exact avec quand même un champ USERAGENT en VARCHAR(255) où on ne stockera que les USERAGENT qui après traitement ne corespondent pas à un navigateur ou OS référencé afin de faire évoluer la liste facilement.

Comment comptes-tu distinguer une deuxième visite d'une visite qui se continue ? Session fermée = fin de visite ?

Pour moi, ce qui semble le plus facile à faire est : session fermée = fin de visite. Le sessid étant normalement unique, c'est lui qui peut même me permettre de gérér mes visiteurs en utilisant cette information comme clef unique dans ma table principale ?

Si ce n'est pas déjà fait, il faut également que tu penses au cas de plusieurs utilisateurs d'un même réseau qui visitent le site. Il risque donc d'y avoir plusieurs couples (sessId, ip) en même temps.

D'où l'intérêt de travailler avec des sessions, je pense.

Je vais vous poster en soirée une architecture sur deux tables avec quelques explications. Vous pourrez alors me donner vos avis et conseils sur quelque chose d'un peu plus concret.

Merci,
Mathieu

[Biglo]

C'est exact avec quand même un champ USERAGENT en VARCHAR(255) où on ne stockera que les USERAGENT qui après traitement ne corespondent pas à un navigateur ou OS référencé afin de faire évoluer la liste facilement.

Oui pourquoi pas. Et dès que tu auras traité ce nouvel user agent, il suffira de mettre à jour les clés étrangères et de remettre à NULL le useragent.

Pour moi, ce qui semble le plus facile à faire est : session fermée = fin de visite. Le sessid étant normalement unique, c'est lui qui peut même me permettre de gérér mes visiteurs en utilisant cette information comme clef unique dans ma table principale ?

Je me suis également posé la question. Mais théoriquement, un numéro de session peut être réutilisé dans le futur. Donc le numéro de session n'est pas unique dans le temps. Je ne sais pas s'il y a une seule clé primaire naturelle. Le couple (idSess, IP) est déjà mieux mais pas tout à fait unique, même si la probabilité d'avoir le même couple est vraiment faible.

Bonne continuation