Gestion des UNION pas comprise

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Gestion des UNION pas comprise

par Brian » 18 avr. 2008, 21:55

C'est très astucieux... Bravo !

Définitivement réglé ! Encore merci.

par Hubert Roksor » 18 avr. 2008, 21:42

Ah oui c'est vrai, l'ajout d'une colonne remet en cause le dédoublenement d'UNION [DISTINCT].

En fait, ce qu'il faudrait changer, c'est la façon de procéder : tu utilises une UNION alors que le premier set est un sous-set du second. Puisque tu te sers d'UNION pour trier les résultats, on devrait pouvoir faire une requête équivalente en utilisant un ORDER BY adapté.

Cette requête devrait être fonctionnellement équivalente, à tester.

Code : Tout sélectionner

SELECT s2.sujet_id, COUNT(*) AS cnt, MAX(s2.sujet_nom LIKE '%[Réglé]%') AS regle FROM fsb_messages m2 JOIN fsb_sujets s2 USING ( sujet_id ) WHERE s2.sujet_nom LIKE '%asm%' GROUP BY s2.sujet_id ORDER BY regle DESC, cnt DESC

par Brian » 18 avr. 2008, 21:28

En fait le sujet n'est pas résolu !

Image

Cette méthode n'enlève pas les doublons... Et oui, les n diffèrent

par Hubert Roksor » 17 avr. 2008, 19:52

Le manuel est vraiment la source n°1 d'aide, et effectivement il n'est pas très à jour.

Pour le reste, pas de problème du moment que la prochaine fois tu pars du bon pied du premier coup ;)

par Brian » 17 avr. 2008, 19:46

Merci beaucoup, tu es très bon ! Je ne serai jamais allé voir dans la bible... Je ne savais pas que les manuels n'étaient que partiellement traduit ! C'est bon à savoir...

Mille mercis et désolé d'avoir été un peu chiant...


Brian

par Hubert Roksor » 17 avr. 2008, 19:34

La réponse se trouvait comme souvent dans le manuel (pas trouvé dans la VF)
[...] use of ORDER BY for individual SELECT statements implies nothing about the order in which the rows appear in the final result because UNION by default produces an unordered set of rows
Contrairement à ce que je pensais, UNION ne conserve pas l'ordre des enregistrement, il te faut donc ordronner l'UNION complète. Afin de différencier les résultats des deux parties de l'UNION, on ajoute une colonne supplémentaire

Code : Tout sélectionner

( SELECT 0 AS n, s2.sujet_id, COUNT(*) AS cnt FROM fsb_messages m2 JOIN fsb_sujets s2 USING ( sujet_id ) WHERE s2.sujet_nom LIKE '%asm%' AND s2.sujet_nom LIKE '%[Réglé]%' GROUP BY s2.sujet_id ) UNION ( SELECT 2 AS n, s2.sujet_id, COUNT(*) AS cnt FROM fsb_messages m2 JOIN fsb_sujets s2 USING ( sujet_id ) WHERE s2.sujet_nom LIKE '%asm%' GROUP BY s2.sujet_id ) ORDER BY n ASC, cnt DESC

par Brian » 17 avr. 2008, 19:21

Merci pour ta réponse...

Image

Mais il me semble que ca ne soit pas ca...

par Hubert Roksor » 17 avr. 2008, 19:05

J'imagine que ta question est "pourquoi les résultats de la seconde moitié de l'UNION ne sont pas dans le même ordre que la seconde requête seule". C'est parce que la clause ORDER BY que tu utilises n'indiques pas comment résoudre les égalités. Si plusieurs enregistrements partagent la même valeur de COUNT(*), ils finissent dans un ordre imprédictible. Tu peux décider d'un départage à partir d'une colonne tierce, par exemple

Code : Tout sélectionner

ORDER BY COUNT(*) DESC, s2.sujet_id DESC

par Brian » 17 avr. 2008, 18:52

Pour la requête :

Code : Tout sélectionner

SELECT s2.sujet_id FROM fsb_messages m2 JOIN fsb_sujets s2 USING ( sujet_id ) WHERE s2.sujet_nom LIKE '%asm%' AND s2.sujet_nom LIKE '%[Réglé]%' GROUP BY s2.sujet_id ORDER BY COUNT(*) DESC) UNION (SELECT s2.sujet_id FROM fsb_messages m2 JOIN fsb_sujets s2 USING ( sujet_id ) WHERE s2.sujet_nom LIKE '%asm%' GROUP BY s2.sujet_id ORDER BY COUNT(*) DESC)
La structure:

Code : Tout sélectionner

-- -- Structure de la table 'fsb_messages' -- CREATE TABLE fsb_messages ( message_id int(11) NOT NULL auto_increment, forum_id mediumint(9) NOT NULL default '0', sujet_id int(11) NOT NULL default '0', membre_id int(11) NOT NULL default '0', pseudo_posteur varchar(30) collate latin1_general_ci NOT NULL default '', message_texte text collate latin1_general_ci NOT NULL, message_temps int(20) NOT NULL default '0', message_ip varchar(20) collate latin1_general_ci NOT NULL default '', PRIMARY KEY (message_id), KEY message_id (message_id), KEY sujet_id (sujet_id) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci; -- -------------------------------------------------------- -- -- Structure de la table 'fsb_sujets' -- CREATE TABLE fsb_sujets ( sujet_id int(11) NOT NULL auto_increment, forum_id int(11) NOT NULL default '0', membre_id int(11) NOT NULL default '0', sujet_nom varchar(250) collate latin1_general_ci NOT NULL default '', nb_vu int(11) NOT NULL default '0', nb_reponse int(11) NOT NULL default '0', dernier_message_id int(11) NOT NULL default '0', dernier_message_temps int(11) NOT NULL default '0', premier_message_id int(11) NOT NULL default '0', sujet_type smallint(6) NOT NULL default '0', sujet_status tinyint(4) NOT NULL default '1', PRIMARY KEY (sujet_id), UNIQUE KEY sujet_id (sujet_id) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLAT

par Hubert Roksor » 17 avr. 2008, 18:46

On n'est pas là pour jouer aux charades et chercher à deviner au hasard la cause de ton problème. Pour régler un problème SQL, on applique toujours la même méthode, en commençant par examiner les requêtes utilisées et les tables auxquelles ces requêtes s'appliquent. Tu ne peux pas demander aux gens d'"expliquer un résultat" si tu n'expliques pas comment tu le génères.

Il y a un règlement et des pratiques en place pour faciliter l'usage du forum et préserver la qualité des questions comme des réponses. Si tu n'es pas prêt à les suivre j'ai bien peur que tu aies à t'adresser ailleurs.

par Brian » 17 avr. 2008, 18:35

Je ne vois pas en quoi ca va faire avancer le problème...
Trop de rigidité tue la rigidité ?

Brian

par Hubert Roksor » 17 avr. 2008, 17:08

Lis mon post précédent et suis les indications.

Re: Gestion des UNION pas comprise

par Brian » 17 avr. 2008, 17:07

Bonjour,

Lorsque j'exécute la première requête, j'obtiens les enregistrement suivants : 540-661
---------------------la seconde requête........................................................:177-838-825-540-661-527
---------------------les deux requêtes avec UNION.......................................:540-661-177-527-825-838

Comment expliquer ce résultat ? Merci par avance.

Brian
J'ai du mal m'exprimer... Pourquoi n'a-t-on pas 540-661-177-838-825-527 ?

par geqr » 17 avr. 2008, 16:51

Beh avec ce qu'à dit dspe ton résultat devient évident..soit, l'ajout des résultats de la seconde requête à ceux de la première en retirant les doublons. D'où le nom de "union" de 2 requêtes.

Image

par Brian » 17 avr. 2008, 16:21

Imagine 2 cercles avec tout un tas de chiffres
Certains chiffres se retrouvent à la fois dans l un et dans l autre
L union t affiche l'ensemble des 2 cercles et ne t affiche pas en doublons d'ou ton résultat
Merci mais c'est deja connu !