Re: [Spip-zone-commit] r97979 - in _core_/branches/spip-3.0/plugins/statistiques

Hello,

tcharlss a écrit :
> Mais ça complique un peu le code et ça éparpille les données, dans ce
> cas je ne sais pas ce qui est préférable : tout basculer dans les
> nouvelles tables, ou garder cette dichotomie (pour rétrocompatibilité ?).

ne pas casser le fonctionnement du core, et surtout éviter de perdre les 
stats si l'on doit désactiver le plugin ultérieurement parcequ'il génère 
des problèmes de perf ou autre est un gros plus.

De ce point de vue c'est bien de garder en l'état. Mais ça veut dire 
aussi qu'on ne bench pas le problème de perf principale, puisque la 
table la plus grosse et la plus historique ne passe pas en 
objet/id_objet, ce qui est le soucis de perf potentielle.
Peut-être il faudrait que le plugin fasse un double enregistrement : 
dans la nouvelle table et dans la table historique. Ça te permet d'avoir 
le code simplifié partout, sauf au niveau de l'enregistrement, et de 
tester les tables objets avec des données réelles (en faisant du coup un 
import depuis les tables historiques lors de l'installation)


Pour le problème de taille des données, c'est en général les tables des 
visites_articles et referers_articles qui explosent avec le temps, et 
c'est une combinaison de :
- le temps (chaque jour un nouvel enregistement)
- le nombre d'article en base (chaque article a potentiellement un 
enregistrement) (et donc par extrapolation le nombre et le type d'objet 
dont tu vas suivre les stats)
- les visites effectives (chaque article qui a au moins une visite 
provoque un enregistrement)
- les liens entrant/le referencement du site (chaque referer cliqué vers 
un article provoque un enregistrement)

Il est sur que si on veut tester un peu sérieusement il faudra le mettre 
en place sur un site comme contrib, a condition d'avoir une reprise de 
l'historique pour ne pas devoir attendre 10 ans, et que ce soit reversible.
(mais a court terme je n'ai pas du tout le temps de regarder ça)

-- 
Cédric