Faire une requête "pondérée"

Répondre
maxroucool
le 28/02/2008 à 11:21
maxroucool
Slt tlm,

je voudrais faire une requête MySQL "pondérée". Ca veut pas dire grand chose comme ca dc je vous explique!

En fait un peut comme wikio, je voudrais sélectionner des éléments en fonction de leur date de publication et du nombre de points qu'ils ont obtenus. Ainsi les enregistrements qui ont moins de deux jours mais que deux points ne sont pas sélectionnes, par contre un enregistrement qui a une semaine mais 25 points l'est.
C'est pour ca qu'il faudrait pouvoir pondérer les champs "date" et "points" pour pouvoir faire ressortir les enregistrements qui on la meilleure moyenne.

Je sais vraiment pas si c'est possible donc je vous demande, mais sinon je trouverais bien un moyen de me débrouiller!


Merci bp!
+++
i M@N
le 28/02/2008 à 12:48
i M@N
Hello.

Juste une idée ...
Dans ta boucle de résultats pour un enregistrement donné quand tu récupères $date et $points tu peux calculer le nombre $nb de jours écoulés jusqu'à l'instant t et tu mutiplies $nb par $points, tu mets toussa dans un tableau $array[] que tu classes par total (sort)

@+...
One Love, One Heart, One Unity.
maxroucool
le 28/02/2008 à 14:25
maxroucool
Slt,

oui dans l'idée c'est a peu près ce que je veux faire. Mais si je l'applique comme tu le dis, c'est pas très optimisé, parce que je devrais sélectionner disons les 50 derniers enregistrements pour au final n'en afficher que 10.

C'est pour ca que je voudrais savoir si MySQL peut le faire direct.


Merci bp!
+++
LupusMic
le 28/02/2008 à 14:54
LupusMic
(i M@N) Non, les traitements de sélections sont à faire avec la requête SQL.

(maxroucool) Il faut que tu traduises ton français en logique. C'est une juste un problème de formulation :

select * from articles where published > subdate(now(),2) or weight > 25 order by published, weight
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
maxroucool
le 28/02/2008 à 16:29
maxroucool
Slt lupus,

j'avais déjà pensé a faire ca, mais en y repensant, je me dis que ca peut être une bonne idée.
Mais il faut y apporter quelques améliorations.

Le champ de la date est de type DATETIME (dc 0000-00-00 00:00:00), mais pour que les résultats soient plus pertinents, il faudrait que lorsque MySQL range les enregistrements par date, il ne considére que les heures, et pas les minutes ou secondes. Sinon le "ORDER BY weight" ne servirait a rien, puisqu'il faudrait que les deux enregistrements aient la même date (à la seconde près!!) pour que MySQL les range ensuite par weight!

J'ai essayé de lire la page de doc , mais j'y comprend pas grand chose!!


Merci bp!
+++
LA GLOBULE
le 28/02/2008 à 20:21
LA GLOBULE
Evidemment, tu pourrais calculer uniquement le jour des dates avec un DATE_FORMAT, mais cela obligerait MySQL à calculer le jour de chaque date de la table, en gros, il analysera toute la table (niveau optimisation, c'est nul).

Ce que je ferais à ta place : une table contenant des résultats en dur, table que je remplirais toutes les nuits avec les résultats de la veille.

En tout cas, si tu fais ce genre de calcul en live, c'est pareil, MySQL ne va pas kiffer.
LupusMic
le 29/02/2008 à 15:54
LupusMic
Quel dommage que MySQL ne supporte pas les index calculés :-/
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
maxroucool
le 29/02/2008 à 19:57
maxroucool
OK la globule, je vais voir ce que ca donne niveau perf, et si c'est vraiment plus gourmand de générer le résultat en direct, je ferais une seconde base qui mémorise l'ordre d'apparition des enregistrements.

Merci bp!
+++
Répondre

Ecrire un message

Votre message vient d'être créé avec succès.
LoadingChargement en cours