Comment faire comprendre à un ORDER BY que -7 c'est plus petit que -2

Bonjour, dans mon classement de foot, il y a tout qui fonctionne comme je veux sauf le 2e critères de tri, à savoir la différence de buts.

Par exemple dans mes essais j'ai ça

N Clubs P J G N P Pr Ctre diff
17 Toulouse 0 2 0 0 2 2 8 -6
18 Lorient 0 2 0 0 2 3 7 -4

Or Toulouse devrait être derrière Lorient, car -6<-4.

Bon pour les différences positives, forcément ça marche impeccablement.

Dans ma requête sql, j'ai ceci :

Code:

---

$sql="SELECT * FROM $stats.ligue1 ORDER BY points DESC, diff DESC, pour DESC, equipe ASC ";

---

Mon type de données pour diff (seul champ à pouvoir être négatif ou positif), est int(11). Certes int je pensais que c'était entier et pas relatifs, mais apparemment les nombres négatifs s'affichent bien aussi donc..

Bon ben j'ai contourné le problème, en créant un autre champ.

j'ai utilisé la 2e solution sur cette page :

http://forum.webrankinfo.com/mysql-t...fs-t87722.html

Re

Citation:

---

Mon type de données pour diff (seul champ à pouvoir être négatif ou positif), est int(11). Certes int je pensais que c'était entier et pas relatifs, mais

---

Et bien la doc pour le type INT ;)
-> http://dev.mysql.com/doc/refman/5.0/...ric-types.html
l'intervalle de validité d'une colonne d'entiers INT va de -2147483648 à 2147483647
Ce qui fait que pour certains de tes champ, un TINYINT ou un SMALLINT pourrait très faire affaire, et économiser de la mémoire surtout.


Pour ce qui est du tri, et bien il faudrait ASC (ascendant) plutôt que DESC (descendant) pour le champ diff.
Normal, car ASC commencera par le plus petit au plus grand, donc -6 puis -4.

Aussi, peut être faudrait il inverser certains champ dans le ORDER BY, comme faire d'abord le tri sur le diff et après les points :

Code:

---

ORDER BY diff DESC, points ASC, pour DESC, equipe ASC

---

Les tri se font dans l'ordre indiqué : (dans cet exemple)
En 1er diff ascendant, ensuite points ascendant, pour descendant et equipe ascendant.

Merci RuneCodePhp pour ces éléments,

mais les points doivent être le premier critères de tri.

Pour le tri négatif, je n'ai mis que deux enregistrements qui illustraient le problème initial, mais la différence n'est pas toujours négative, sur l'ensemble du classement :

Donc il faudrait que je trie en DESC toutes les différences au dessus de 0, et en ASC celles qui sont en dessous.

Ceci me compliquant trop la tâche, j'ai pris une deuxième colonne diff2, dans laquelle je mets le nombre 100 et à laquelle je rajoute la diff. Si diff est de -2, diff2 sera de 98, et je trie en fonction de diff2. Par contre j'affiche diff.

C'est pas toujours très clair avec les noms de variables que je prends mais bon. ;)

sinon j'ai vu qu'il y avait un truc avec le unsigned, mais moi j'ai pas signé et pas signé, j'ai que unsigned, unsigned zerofill, binary et un autre truc.

Je vois un peu mieux, et la cause de ton problème.
J'ai jamais eu à gérer de genre de cas, alors du coup, j'en sais rien.

Je trouve juste dommage qu'il faille jusqu'à créer un nouveau pour ça.
C'est de la redondance de données, et théoriquement c'est le genre de truc à éviter.
Mais comme j'ai pas d'idée qui me vient, j'ai rien à te proposer. :oops:


Pour le unsigned, c'est pour définir si le champ de type numérique accepte ou pas de signes négatif.
Si tu as des champs qui ne doivent pas en avoir (genre résultat de match, clés, etc ...), alors faut spécifier unsigned.
D'ailleurs, le fait de spécifier unsigned aura pour effet de doubler la capacité du champ (petit truc que j'ai appris il y peu, ça peu être utile).

C'est vrai que ça ne me plaisait pas non plus d'avoir à créer une autre colonne exprès, mais bon du moment que ça règle le problème je ne vais pas faire la fine bouche. :)

Pour le signed/unsigned je l'ai appris aujourd'hui ben en cherchant pour ce problème, que comme le int est codé sur 4 octets, si on prend signed ça va allouer 2^32 bits allant donc de 0 à 4 294 967 296.

Si on prend unsigned, ça va diviser par 2 pour les positifs car ça fait moitié-moitié pour les négatifs et positifs, donc ça alloue 2^31 bits allant de -2 147 483 648 à 0 pour les négatifs et de 0 à 2 147 483 648 pour les positifs.

Il me semble avoir mieux compris ton problème.

Théoriquement, il ne faudrait pas enregistrer la différence qu'il y a entre les rencontres, mais un calcul qui se ferait dans la requête (donc à la volée).

En procédant ainsi, (et théoriquement), plus besoin de ce champ, et du 2ème aussi, qui permettra de faire le trie que tu veux.
D'ailleurs, ces résultats sont de la redondances, genre de truc qu'il vaut mieux éviter.
En règle général, on effectue ce genre de chose dans un but d'optimiser une BDD (ou une table), ça se fait particulièrement pour des statistiques.

Exemple :

Code:

---

1 2 3

SELECT clubs, points, pour, contre, (pour - contre) AS difference, ((pour - contre) + 100) AS diff_trie FROM $stats.ligue1 ORDER BY points DESC, diff_trie ASC, pour DESC, equipe ASC

---

Ici, l'alias "diff_trie" est juste là pour faire le tri (ASC ou DESC je ne sais plus)
L'alias "difference" devient l'équivalent du champ actuel diff, que tu peux exploiter dans l'affichage.

Eh bien ta façon marche impeccablement :ccool:

Merci pour cette optimisation. Si j'ai le temps je chercherai un petit script ou une fonction qui calcule le temps de chargement de la page, comme ça je verrai un peu le gain de temps.

Je vais supprimer le champs diff2, en revanche, je pense garder l'autre. En fait ce champ j'en ai besoin, et dans mes requêtes, je compte faire plusieurs tris, dont un par la différence de buts.

Certes, je pourrais faire de la même façon que tu as faite, en calculant à la volée à partir de "pour" et "contre".

D'ailleurs, je pourrais procéder de la même façon pour les points, je pourrais supprimer la colonne "points" étant donné que cette donnée est calculée par le nombre de victoire * 3pts, + le nombre de nuls *1pt.

Mais je ne sais pas, comme je préfère avoir dans ma base le classement avec toutes les données, j'hésite encore.

Je pense que je pourrai me décider plus facilement après avoir calculé le temps d'exécution, si je note une grande différence ou pas.

Je te tiendrai au courant et encore merci ;)

Ah voilà !

C'est super intéressant de faire ça, je calculais les temps d'exécution quand je codais en C, mais jamais mes pages php :)

J'ai trouvé ce script, sur http://fr.php.net/manual/fr/function.microtime.php

Code:

---

1 2 3

function getmicrotime(){ list($usec, $sec) = explode(" ",microtime()); return ((float)$usec + (float)$sec); }

---

Avec ta façon (en ne supprimant que la colonne diff2) :

Citation:

---

Page générée en 0.109 secondes

---

Avec ma façon (j'ai dû du coup recréer la colonne diff2 et remettre comme avant) :

Citation:

---

Page générée en 0.166 secondes

---

Franchement je vais t'écouter, et je vais optimiser à fond, je vais peut être supprimer la colonne diff aussi, et peut être même la colonne points.

Je ne sais pas si j'aurai le temps aujourd'hui, mais dès que j'ai fait tout ça, je t'en donnerai des nouvelles. :ccool:

dsl ça fait 3 messages que je laisse d'un coup,

je dis que je le ferai plus tard mais je suis trop impatient.

j'ai fait :

Code:

---

$sql="SELECT equipe, gagne, nul, (gagne*3 + nul) AS points , perdu, ...

---

Le temps d'exécution ne semble pas diminuer conséquemment.

Aussi j'ai complexifié le calcul en mettant n'importe quoi :

Code:

---

$sql="SELECT equipe, gagne, nul, ((gagne*3 + nul - perdu*7)%12 ) AS points , ...

---

Et là à ma grande stupéfaction, ça ne semble avoir quasiment aucun impact sur le temps de chargement qui reste sensiblement le même, mais ça prouve que tu avais raison, ça ne prend pas beaucoup de ressources.

En résumé, j'ai un peu de mal à comprendre pourquoi en supprimant diff2, ça diminue d'environ 0,050 secondes, et en supprimant diff et points, ça diminue d'environ 0,005 secondes.

Remarque je ne me souviens pas de si j'avais déjà (ou pas) supprimer les champs dans le SELECT, je l'ai peut être pas bien fait.

Mais de toute façon, je préfère opter pour ta solution, garder un minimum de champs. Surtout que ça me simplifie le code php en rajoutant une portion de ligne dans le SQL, et ça ne serait-ce que pour la lisibilité, c'est très appréciable.

J'ai même comparé avec la pièce jointe que j'avais laissée hier, et c'est le même classement, donc malgré toutes les modifications, tout semble fonctionner. :)