Discussion :

[Kijer]

Bonjour,

Je bosse actuellement sur un site de vidéos où chaque vidéo incrémente son compteur de vues à chaque visite unique de cette page.

Je souhaite faire une page TOP100 par jour / semaine / mois /année et detouslestemps.

Ce même classement pourra être toutes catégories confondues ou sur une catégorie précise.

Je n'ai jamais implémenté de système de classement et n'est donc pour l'instant qu'un simple champ "nbre_vues" en INT sur ma table videos.

Vous, par expérience, quelle structure mettriez-vous en place pour réussir cette mise en place ?

C'est à dire :
- le TOP 100 par période
- Et que je puisse à tout moment afficher le classement global de la vidéo sur sa fiche.


Merci d'avance.

[rawsrc]

Salut

Le plus simple, serait que tu horodates l'incrémentation du compteur de vues pour chaque vidéo

[Kijer]

Merci de ta réponse.
Donc ce qui sous entend une table "videos_vues" ?

avec

id INT
video_id INT
date DATETIME

c'est ça ?

Et une REQ du genre :

Code sql :

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

SELECT videos.*, COUNT(vues.video_id) AS nbre_vues FROM videos JOIN videos_vues vues ON vues.video_id = videos.id ORDER BY nbre_vues LIMIT 100

?

[rawsrc]

Oui.
Par contre n'utilise pas une colonne nommée date, c'est généralement un mot réservé par le moteur SGBD.
Evite le SELECT * FROM, liste plutôt les colonnes.
Après à toi de jouer sur les périodes pour parvenir à tes fins.

[Kijer]

Ok niquel.
Pour la requête, j'ai effectivement raccourci mon écriture pour l'exemple.

Me reste 2 questions :

- Si ya 1000,10000,100 000, 1 000 000 de pages vues, ca risque pas de réduire considérablement le calcul/chargement de la page/site ?
- Et comment faire "Cette vidéo est classé x/123 dans la cat x, et x/1452 sur tout le site".
Merci !

EDIT : J'ai peut-être un semblant de solution, au lieu de faire une insertion par page vue, rajouter plutot un champ "vues" sur cette table, et il n'y aura que 365 entrées/page par an. Champ que j''update ou ajoute si le jour est différent.

[rawsrc]

Une table avec 1 million d'enregistrements du style id | id_video | datetime c'est ridicule avec les index qui vont bien.

Je ne pense pas que ton approche d'associer un calendrier vide à chaque vidéo pour chaque année soit tip top. Il n'y a aucun intérêt à réserver de l'espace pour des données qui ne seront peut-être jamais renseignées (une semaine sans vues par exemple).
Je procéderai autrement : pour éviter de tout recalculer (et si vraiment tu constates un ralentissement significatif), je créerai une table de stats standard pour les périodes passées avec le cumul des compteurs.
Ensuite toujours pour améliorer les performances, tu pourrais aussi purger régulièrement dans une autre table les anciennes données de la table courante.

Après, ne connaissant pas quel SGBD tu utilises ni le format des tables, je te dirais que COUNT(*) est généralement très lent. Parfois, en passant par un simple SUM() tu pourrais y gagner en célérité.

Mets d'abord en place ce que tu souhaites faire et penches toi ensuite à l'usage sur les optimisations.
Pour les aspects dynamiques des stats, je te conseille très fortement de les coder sous forme de procédure/fonction stockée et de profiter ainsi des divers optimisations que t'apporte un SGBD (tables temporaires, chargement en mémoire vive, compilation...).