Order by DESC sur AVG(champ) -> NULL placés en premier (mysql)

Order by DESC sur AVG(champ) -> NULL placés en premier (mysql) - SQL/NoSQL - Programmation

Marsh Posté le 11-07-2005 à 22:09:37    

J'édite mon message pour un nouveau problème très étrange. Voici ma requète :
 


SELECT AVG(sucre) AS sucre, AVG(qualite) AS qualite, AVG(gout) AS gout, parfum, marque, count(sucre) AS nb_eval, tabacs.id
FROM tabacs
LEFT OUTER JOIN tabacs_notes ON tabacs.id=tabacs_notes.tabac
GROUP BY tabac, tabacs.id
ORDER BY sucre DESC  
LIMIT 00, 10


 
Cette requète me retourne toute la liste ordonnée comme il faut mise à part les valeurs NULL qui sont placées en premier.
 
Et pourtant selon la doc officielle ( http://www.nexen.net/docs/mysql/an [...] h-null.php ) :

Citation :


 Lors de l'utilisation de ORDER BY  , les valeurs NULL  sont présentées en premier. Si vous triez dans l'ordre décroissant en utilisant DESC  , les valeurs NULL  sont présentées en dernier. Lors de l'utilisation de GROUP BY  , toutes les valeurs NULL  sont considérées comme égales.


 
Si quelqu'un comprend pourquoi ça ne suit pas la règle de base ... merci de m'expliquer  :jap:  
 
---------
 
Salut,
 
Voici ma requète :
 


SELECT AVG(sucre), AVG(qualite), AVG(gout), parfum, marque, count(sucre), tabacs.id
FROM tabacs, tabacs_notes
WHERE tabacs.id=tabacs_notes.tabac
GROUP BY tabacs_notes.tabac
ORDER BY count(sucre)
LIMIT 0, 10


 
J'obtiens l'erreur suivante : Invalid use of group function
 
Mysql refuse le ORDER BY COUNT(...) ou ORDER BY AVG(...).
 
Comment puis-je faire alors pour pouvoir classer mes résultats par la note de qualité moyenne (AVG(qualite)), nombre de lignes dans la table tabacs_notes (count(sucre)), etc ?
 
Merci  :hello:
 


Message édité par albataur le 12-07-2005 à 15:55:39
Reply

Marsh Posté le 11-07-2005 à 22:09:37   

Reply

Marsh Posté le 11-07-2005 à 23:10:07    

rajoute le count(sucre) dans le GROUP BY ou fais un mets un AS sur tes fonctions (si c'est faisable en MySQL, en tout cas ça marche avec SQLServer)

Reply

Marsh Posté le 12-07-2005 à 00:08:41    

Merci beaucoup  :jap:  
C'était tout simplement ça le problème  :pt1cable:  
Voici la version qui marche :
 


SELECT AVG(sucre) AS sucre, AVG(qualite) AS qualite, AVG(gout) AS gout, parfum, marque, count(sucre) AS nb_eval, tabacs.id
FROM tabacs, tabacs_notes
WHERE tabacs.id=tabacs_notes.tabac
GROUP BY tabacs_notes.tabac
ORDER BY nb_eval DESC
LIMIT 0, 10

Reply

Marsh Posté le 12-07-2005 à 15:56:28    

Salut,
 
A peine résolu j'ai un nouveau problème depuis hier soir, voici ma requète :
 


SELECT AVG(sucre) AS sucre, AVG(qualite) AS qualite, AVG(gout) AS gout, parfum, marque, count(sucre) AS nb_eval, tabacs.id
FROM tabacs
LEFT OUTER JOIN tabacs_notes ON tabacs.id=tabacs_notes.tabac
GROUP BY tabac, tabacs.id
ORDER BY sucre DESC  
LIMIT 00, 10


 
Cette requète me retourne toute la liste ordonnée comme il faut mise à part les valeurs NULL qui sont placées en premier.
 
Et pourtant selon la doc officielle ( http://www.nexen.net/docs/mysql/an [...] h-null.php ) :

Citation :


 Lors de l'utilisation de ORDER BY  , les valeurs NULL  sont présentées en premier. Si vous triez dans l'ordre décroissant en utilisant DESC  , les valeurs NULL  sont présentées en dernier. Lors de l'utilisation de GROUP BY  , toutes les valeurs NULL  sont considérées comme égales.


 
Si quelqu'un comprend pourquoi ça ne suit pas la règle de base ... merci de m'expliquer  :jap:

Reply

Marsh Posté le 12-07-2005 à 16:22:32    

je me demande si ce n'est pas une erreur dans la doc, parceque logiquement, NULL a un fonctionnement spécial, ce n'est pas une valeur. du coup, la présence des NULL tout le temps en haut quelque soit l'ordre de tri ne m'étonne pas.
 
dans tous les cas, je te conseille de remplacer les NULL par des 0 avec l'instruction NVL() (ou ISNULL() ou un truc du genre, je ne connais pas assez MySQL)

Reply

Marsh Posté le 12-07-2005 à 16:25:09    

Quoiqu'en effet, avec SQL Server, ça se comporte comme d'après la doc de MySQL :
 

Code :
  1. select distinct DiscoveryLink
  2. from asset
  3. order by DiscoveryLink
  4. select distinct DiscoveryLink
  5. from asset
  6. order by DiscoveryLink desc


 

Code :
  1. DiscoveryLink                   
  2. --------------------------------
  3. NULL
  4. 0
  5. a facturer
  6. ADD-NEW
  7. Avoir
  8. Commande
  9. EnCoursSortie
  10. Expedition
  11. installation
  12. LPCX
  13. LPCY
  14. NonLivre
  15. P6 : 5966
  16. P6 : 5967
  17. P6 : 5972
  18. P6 : Vol Micro
  19. ParcFP
  20. ParcLoue
  21. ParcSpec
  22. Sortie
  23. Vente
  24. Vente User
  25. Vol
  26. (24 ligne(s) affectée(s))
  27. DiscoveryLink                   
  28. --------------------------------
  29. Vol
  30. Vente User
  31. Vente
  32. Sortie
  33. ParcSpec
  34. ParcLoue
  35. ParcFP
  36. P6 : Vol Micro
  37. P6 : 5972
  38. P6 : 5967
  39. P6 : 5966
  40. NonLivre
  41. LPCY
  42. LPCX
  43. Installation
  44. Expedition
  45. EnCoursSortie
  46. Commande
  47. Avoir
  48. ADD-NEW
  49. a facturer
  50. 0
  51. NULL
  52. (24 ligne(s) affectée(s))


 
Mais bon, moi dans tous les cas, je pense qu'un :
 

Code :
  1. select distinct isnull(DiscoveryLink, 0) toto
  2. from asset
  3. order by toto


 
Est mieu :
 

Code :
  1. toto                           
  2. --------------------------------
  3. 0
  4. a facturer
  5. ADD-NEW
  6. Avoir
  7. Commande
  8. EnCoursSortie
  9. Expedition
  10. installation
  11. LPCX
  12. LPCY
  13. NonLivre
  14. P6 : 5966
  15. P6 : 5967
  16. P6 : 5972
  17. P6 : Vol Micro
  18. ParcFP
  19. ParcLoue
  20. ParcSpec
  21. Sortie
  22. Vente
  23. Vente User
  24. Vol
  25. (23 ligne(s) affectée(s))

Reply

Marsh Posté le 12-07-2005 à 16:47:40    

Merci pour tes réponses.
 
Effectivement il y a une erreur dans la doc mysql apparement :
 
http://www.nexen.net/docs/mysql/an [...] ?lien=null

Citation :


Lorsque vous utilisez la clause ORDER BY  , les valeurs NULL  sont toujours triées en premier, même si vous utilisez l'attribut DESC  .


 
Faudrait se mettre d'accord ...
 
Il faudrait que je trouve un moyen de transformer mes valeurs null en 0 ou -1 à l'intérieur de ma requète mais je vois pas trop comment faire ...

Reply

Marsh Posté le 12-07-2005 à 16:50:50    

arf :)
 
dans tous les cas, à moins que ça ne pollue tes résultats, je te conseille de remplacer les NULL renvoyés par AVG par 0, ou une valeur bidon isolable. Comme ça, le problème ne se pose plus ;)

Reply

Marsh Posté le 12-07-2005 à 16:56:15    

Ok, la traduction fr a un problème apparement puisque la version en m'apprend que :  When using ORDER BY, NULL  values are presented first, or last if you specify DESC to sort in descending order. Exception: In MySQL 4.0.2 through 4.0.10, NULL values sort first regardless of sort order.
 
Edit: c'est même pas ça mon problème en fait puisque je suis en 3.23.58


Message édité par albataur le 12-07-2005 à 17:00:55
Reply

Marsh Posté le 12-07-2005 à 17:02:08    

Ah ouais quand même, c'est édifiant :D
 
J'ai enfin une raison écrite en toute lettres pour pas aimer ce produit :D

Reply

Marsh Posté le 12-07-2005 à 17:02:08   

Reply

Marsh Posté le 12-07-2005 à 17:04:25    

Arjuna a écrit :

arf :)
 
dans tous les cas, à moins que ça ne pollue tes résultats, je te conseille de remplacer les NULL renvoyés par AVG par 0, ou une valeur bidon isolable. Comme ça, le problème ne se pose plus ;)


 
Heu ... j'aimerais bien, ce serait parfait :) mais je connais pas de fonction mysql capable de le faire (isnull ca teste juste si la valeur est null) ?


Message édité par albataur le 12-07-2005 à 17:04:40
Reply

Marsh Posté le 12-07-2005 à 17:12:12    

nan, alors, sous SQL Server, c'est "isnull()" et sous Oracle, c'est "nvl()", donc avec du pot, ce sera une de ces deux là pour MySQL. Sinon, à moins que les développeurs sous MySQL continuent à bouder ce topic, tu devrais avoir une réponse rapide.
 
Dans tous les cas, c'est :
 
isnull(val1, val2) (ou nvl(val1) )
 
=> Où "val1" est la valeur à tester, et :
-> isnull remplace val1 par val2 quand val1 = null
-> nvl remplace val1 par 0 quand val1 = 0
Dans les autres cas, le résultat = val1

Reply

Marsh Posté le 13-07-2005 à 12:31:37    

:bounce: , personne ne sait ?

Reply

Marsh Posté le 13-07-2005 à 14:06:31    

j'ai l'impression que tous les gens qui codent du mysql sont des étudiants, et qu'ils sont tous en vacance... y'a trois pauvres questions qui se battent en duel, alors que d'hab, y'en a 20 par heure où on demande comment faire une jointure avec mysql, et en plus, y'a plus personne qui répond, alors que d'hab y'a 25 réponse aussi erronées les unes que les autres pour chaque post
 
(ouais, je suis pas de marseille, mais je dois avoir des racines cachées de là-bas :D)

Reply

Marsh Posté le 13-07-2005 à 14:06:52    

en tout cas, y'a plus personne qui connait mysql en ce moment j'ai l'impression

Reply

Marsh Posté le 13-07-2005 à 14:14:47    

:) Merci de ton soutien :p
 
J'ai mis un message sur le forum de mysql.com, on verra si ça porte plus ses fruits.

Reply

Marsh Posté le 13-07-2005 à 14:15:38    

heu, pas sur du tout mais je crois que c'est "IFNULL" en mysql...
A vérifier...

Reply

Marsh Posté le 13-07-2005 à 14:28:33    

Merci  :jap:  

Citation :


 IFNULL(expr1,expr2)
    Si l'argument expr1 n'est pas NULL , la fonction IFNULL() retournera l'argument expr1 , sinon elle retournera l'argument expr2 .


 
C'est exactement ce que je cherchais :)

Reply

Marsh Posté le 13-07-2005 à 16:04:40    

arf, isnull, ifnull, s'auraient pu faire un effort pour reprendre le même :D

Reply

Marsh Posté le 25-07-2005 à 23:10:19    

on ne se plaint pas quand on bosse avec une version aussi vieille, non mais, faut pas se moquer du monde non plus !
 
et si la doc FR ne vous plait pas n'hésitez pas à vous proposer en tant que traducteurs ils seront contents d'avoir de l'aide je suis certain.

Reply

Marsh Posté le 26-07-2005 à 09:30:43    

pour info, j'ai vérifié à ce moment que c'était bien un problème de doc dès le départ, en anglais c'est textuellement la même chose.
 
ensuite, la version 5 est toujours à ma connaissance en béta.
 
donc, les versions 4.x sont les versions actuelles.
 
ensuite, c'est pas parceque MySQL sort une sous-version toutes les semaines que sur un serveur de production on doit changer à chaque fois (surtout quand on voit ça, ils refoutent des vieux bugs d'une version à l'autre, ça n'encourage pas à changer de version).
 
Aujourd'hui, je travaille sur des applications fonctionnant avec SQL Server 2000. Il est sorti en 2000 comme son nom l'indique. On est en 2005 tu vois. Il est donc bien plus vieux que MySQL 4.
1/ Les mises à jours majeures sorties ces 5 dernières années sont au nombre de 3 (3 services packs), ce qui indique que la version originale était suffisament stable pour ne pas nécessiter un patch par semaine.
2/ Les services pack en question n'apportent rien ou presque d'un point de vue fonctionnalités/performances. 95% de leur contenu concerne des améliorations de la sécurité.
 
Alors oui, si une version 4.x merde à plein tuble alors que c'est toujours cette version majeur qui est la version "stable", ben je gueule et je crie au scandale, point.
Bosse un peu dans une vraie entreprise, on verra si tu fait une mise à jour par semaine pour pallier aux merdes d'un produit bâclé.
 
La plupart des entreprises qui ont migré de SQL Server 7 à SQL Server 2000 ne l'ont pas fait avant 2003, j'ai récemment bossé sous Oracle 7.1.3 (puis ils ont sauté directement vers une 9i)
 
Dans une vrai société, quand t'as un outil qui fonctionne, et que tu gères ton business avec, ben tu changes pas comme ça. T'attends d'avoir des besoins réels.
 
Alors merde à la fin, fout ta mauvaise foi de côté une bonne fois pour toute.


Message édité par Arjuna le 26-07-2005 à 09:31:12
Reply

Marsh Posté le 26-07-2005 à 13:34:25    

ok je n'ai surement pas ton expérience en entreprise loin de là... mais dans le peu d'entreprises où je suis allé (qui n'avait pas les contraintes des 10000 requetes secondes), MySQL fonctionnait au taquet.
 
Et pour info, MySQL conseille à tous de passer en version 5 (les commerciaux disent ça).
Elle ne doit pas avoir gd chose d'une bêta.
 
Et je comprends que si mettre à jour un SGBD plus souvent que tous les 5 ans t'ennuient, alors reste chez crosoft, ils sont parfaits pour ça. Mais eux ils ne font pas du logiciel libre.
 

Citation :

Alors oui, si une version 4.x merde à plein tuble alors que c'est toujours cette version majeur qui est la version "stable", ben je gueule et je crie au scandale, point.


avec des si, on mettrait paris en bouteille...
 

Citation :


ensuite, c'est pas parceque MySQL sort une sous-version toutes les semaines que sur un serveur de production on doit changer à chaque fois (surtout quand on voit ça, ils refoutent des vieux bugs d'une version à l'autre, ça n'encourage pas à changer de version).

 
 
évidemment si tu n'as pas rencontré LE bug qui a forcé cette version mineure, alors tu ne touches pas à ton serveur... mettre à jour un sgbd car il a un bug fonctionnel, ne doit pas arriver souvent !  
 

Citation :


Bosse un peu dans une vraie entreprise, on verra si tu fait une mise à jour par semaine pour pallier aux merdes d'un produit bâclé.


 
Oui mysql c'est comme linux, c'est baclé  :pt1cable:  :pt1cable:

Reply

Marsh Posté le 26-07-2005 à 13:42:28    

matthieu_phpmv a écrit :


Et je comprends que si mettre à jour un SGBD plus souvent que tous les 5 ans t'ennuient, alors reste chez crosoft, ils sont parfaits pour ça. Mais eux ils ne font pas du logiciel libre.


 
Euhhh... non mais attend là... tu changes pas de version tous les ans dans un SI hein... microsoft ou pas microsoft... les migrations c'est pas gratuit bonhomme :/
 
 

Citation :

évidemment si tu n'as pas rencontré LE bug qui a forcé cette version mineure, alors tu ne touches pas à ton serveur... mettre à jour un sgbd car il a un bug fonctionnel, ne doit pas arriver souvent !


 
Avec MySQL ça arrive un p'tit peu quand même :D
 

matthieu_phpmv a écrit :


Oui mysql c'est comme linux, c'est baclé  :pt1cable:  :pt1cable:


 
c'est pas baclé mais comme ils ont moins les moyens, la qualité ne peut pas être la même que pour les grands éditeurs. C'est pas un reproche, c'est comme ça c'est tout. Alors quand après on voit certain essayer de comparer MySQL avec Oracle ou SQL Server, désolé mais ils ne jouent pas vraiment dans la même cours :/

Reply

Marsh Posté le 26-07-2005 à 13:47:24    

Comment sais tu si ça arrive avec Mysql puisque tu sembles ne pas l'utiliser, tellement pour toi c'est un concurrent ridicule aux yeux des autres ?

Reply

Marsh Posté le 26-07-2005 à 13:53:50    

Ben là où pour moi c'est "bâclé", c'est que mise à part les mises à jours de sécurité qui doivent impérativement être diffusée le plus rapidement possible, MAIS en aucun cas impacter le fonctionnement du produit, pour moi, les autres correctifs concernant des améliorations et des corrections mineures ne doivent pas faire l'objet de sous-versions toutes les semaines.
 
Ceci pour plusieurs raisons :
1/ En entreprise, c'est pas possible de faire une mise à jour aussi régulièrement. A cause des impacts possibles sur les appli existantes, il faut mettre en place une procédure de test/validation de la nouvelle plateforme, et souvent faire des modifications dans le code pour utiliser correctement ces évolutions ou contourner les régressions possibles. Ainsi, ça coûte extrêment cher, et ça reste très risqué, d'autant plus si entre deux versions on n'a pas le temps de finaliser correctement les tests.
2/ A faire 1000 sous-versions, on ne sais jamais à partir de quel moment le produit supporte telle ou telle fonction. Les requêtes imbriquées sous MySQL par exemple, c'est à partir de la version 4.1.x, et le x n'est pas 0, c'est donc une sous-sous-version qui a apporté cette nouveauté. Pour moi, c'est une grossière erreur, ils auraient dû retarder la sortie de la version 4.0, ou au moins attendre la 4.2.0 avant de mettre cette évolution.
 
Je sais pas, ça me semble logique.
 
C'est ce que font tous les autres éditeurs de logiciels (même linux c'est pour dire).
 
Sinon, utiliser un logiciel libre "parcequ'il est libre", pour moi y'a un léger problème quelque part. Moi, j'utilise un outils parcequ'il répond à mes besoins et que le coût nécessaire pour l'aquérir a été accepté par la direction. En aucun cas parceque c'est payant ou que c'est libre.

Reply

Marsh Posté le 26-07-2005 à 13:56:34    

matthieu_phpmv a écrit :

Comment sais tu si ça arrive avec Mysql puisque tu sembles ne pas l'utiliser, tellement pour toi c'est un concurrent ridicule aux yeux des autres ?


c'est pas "un concurrent ridicule", c'est même pas un concurrent.
même la version 5, qui est bien plus évoluée, ne sera pas un concurrent, parceque les nouveautés (PS, Trigger, etc.) sont extrêment lents sur cette version. La version 6 sera peut-être un concurrent d'entrée de gamme, car trigger ou pas, le périmètre fonctionnel est à des années lumière des ténors du SGBD. Au moins, avec cette version, on aura certainement des triggers et PS suffisament rapide pour être utilisables sans mettre en périle son application.

Reply

Marsh Posté le 26-07-2005 à 14:05:40    

matthieu_phpmv a écrit :

Comment sais tu si ça arrive avec Mysql puisque tu sembles ne pas l'utiliser, tellement pour toi c'est un concurrent ridicule aux yeux des autres ?


 
Suffit de savoir lire et voir les parts de marché :)

Reply

Marsh Posté le 26-07-2005 à 21:32:23    

:lol:  
C'était juste une question à l'origine, pas un débat :)


Message édité par albataur le 26-07-2005 à 21:32:33
Reply

Marsh Posté le 26-07-2005 à 21:49:10    

en ce moment tous les posts tournent au pugilat SQL Server vs MySQL

Reply

Marsh Posté le 07-04-2006 à 10:05:41    

C'est tard mais bon...
 
Je ne connais pas bien MySQL
Mais sur Oracle Il y a L'instruction
 
ORDER BY XXXX NULLS FIRST
OU
OREDER BY XXXX NULLS LAST
 
Regarde s'il n y a pas la meme chose sur MySql
car parfois on a besoin du NULL

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed