Faire une requête "pondérée"
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!
+++
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.
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!
+++
(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.
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!
+++
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.
Quel dommage que MySQL ne supporte pas les index calculés :-/
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
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!
+++
Ecrire un message
Votre message vient d'être créé avec succès.
BB-Code
Pour insérer une URL clickable
Pour insérer une adresse E-mail
Pour annoter
Pour écrire du code
Pour faire un lien vers une fonction PHP
Pour écrire du texte préformaté
Pour écrire du texte en gras
Pour écrire du texte en italique
Pour écrire du texte souligné
Pour écrire du texte barré
Pour écrire un titre principal
Pour écrire un titre secondaire
Pour écrire une liste
Smiley
:bond:
:boxe:
:bsmile:
:bump:
:clap:
:coeur:
:cool:
:cry:
:eek:
:evil:
:fleur:
:fou2:
:fou:
:grin:
:grrr:
:hammer:
:hippy:
:hum:
:idee2:
:idee:
:kdo:
:king:
:ko:
:lol:
:love2:
:love:
:mad:
:maitre:
:noel:
:oops:
:raa:
:razz:
:roll:
:sad:
:skull:
:smile:
:timide:
:trink:
:vice:
:vomi:
:wink:
:zzz: