Le BETWEEN ne fonctionne pas non plus malheureusement.
Même message d'erreur.
C'était une bonne idée par contre, merci!
SQL ne peut apparemment pas traiter ce genre de "loop"(contrairement à Visual Basic qui lui prendrait ma condition sans problème)
Je viens d'essayer de faire une query dans ma query.
En fait c'est même DEUX query dans ma query, puisque je dois le faire pour min(x) et pour min(x)+1.
Et comme j'ai vraiment beaucoup de conditions dans ma query original, je dois tous les répéter. AIE, c'est pas super esthétique.
Mais bonne nouvelle....ça roule! Bon, ça ne donne pas ce que je veux, mais j'approche.
Attention je suis pas un pro de mysql mais les query dans les query j'ai tenté c'est la mort en performance... je crois qu'avec une certaine jointure et des alias peut etre left outer join tu doit pouvoir faire ça, mais je me souviens plus trop je vais chercher un peu
Sauf que la clause HAVING ne sert pas à ça, mais à filtrer les groupes (donc, avec une requête incluant GROUP BY)...
La première solution qui me vient en tête aurait été deux sous-requêtes :
-- ...
WHERE x BETWEEN (SELECT MIN(x) FROM table_name) AND (SELECT MIN(x) + 1 FROM table_name)
Après, c'est peut-être pas la solution la plus efficace, quoi qu'il en soit, ça reste plus approprié que le HAVING (qui ne fonctionnerait même pas avec un SGBDR potable)
Sauf qu'il n'y a que MySQL qui accepte HAVING sans la clause GROUP BY (tiens, comme par hasard), que c'est très moche et que ça ne renvoie pas toujours le résultat voulu.
Sauf qu'il n'y a que MySQL qui accepte HAVING sans la clause GROUP BY (tiens, comme par hasard), que c'est très moche et que ça ne renvoie pas toujours le résultat voulu.
Petite question, ça fait quoi un HAVING sans GROUP BY ? Elle porte sur quoi la condition du HAVING ?
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
Le HAVING est au GROUP BY ce que le WHERE est au SELECT.
Imagine que tu comptes la somme des salaires de chaque employé d'une entreprise, ces derniers étant regroupé par département (financier, marketing, informatique, etc.)
Supposons que tu ne veuilles que les département où la somme des salaires soit supérieure à 30000, c'est à ce moment là qu'il faudra utiliser le HAVING SUM(salaire) >= 30000.
D'ailleurs un HAVING sans GROUP BY sous Oracle affiche un très joli message d'erreur
Supposons que tu ne veuilles que les département où la somme des salaires soit supérieure à 30000, c'est à ce moment là qu'il faudra utiliser le HAVING SUM(salaire) >= 30000.
Et dans ce cas là, on regroupe par département dans le GROUP BY, je suis bien d'accord
(en passant, on ne peut pas utiliser des GROUP BY et de HAVING pour le problème posé par lilpac, étant donné que sa condition porte bien sur les lignes et pas sur des regroupements de lignes)
Mais si je reprends un select avec un HAVING sans GROUP BY, comme celui qui est plus haut :
SELECT * from table HAVING x BETWEEN min(x) AND min(x)+1
C'est quoi la sémantique de ce truc ? Toutes les lignes sont placées dans un même groupe et si la condition est fausse, la requête retourne 0 lignes ?
Citation : BlueRat
D'ailleurs un HAVING sans GROUP BY sous Oracle affiche un très joli message d'erreur
+1 pour Oracle
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
La première solution qui me vient en tête aurait été deux sous-requêtes :
-- ...
WHERE x BETWEEN (SELECT MIN(x) FROM table_name) AND (SELECT MIN(x) + 1 FROM table_name)
C'est exactement le chemin que je me suis résolu à emprunter. (une query dans une query youpi!)
Concernant cette façon de faire, dois-je répéter toutes mes conditions de la query principale?
SELECT a, b
FROM table1, table2, table3
WHERE c = d
and e = f
-- ...
and x BETWEEN (SELECT MIN(x) FROM table3 WHERE "?!?!?") AND (SELECT MIN(x) + 1 FROM table_name WHERE "?!?!?!")
Donc, dans les "?!?!?!" dois-je y mettre mes conditions principales c = d et e = f
Pas nécessaire? Permet d'optimiser? Ralentir?
Pas évident d'être clair à l'écrit
Merci encore pour votre aide à tous!
Bah, ça dépend de ce que tu veux sélectionner. La sous-requête va nécessairement sélectionner le plus petit x s'il n'y a pas de WHERE. Bref, c'est toi qui vois.
Je sais pas si ça serait plus efficace de faire deux requêtes séparées : l'une qui va chercher la valeur MIN(x) puis l'autre qui fait ce que tu veux. Le problème avec les deux sous-requêtes (solution que j'ai proposée), c'est qu'on va chercher deux fois la même information, ce qui devrait logiquement être évité si on pouvait stocker le résultat dans une variable.
Je doute toutefois que de faire deux requêtes distinctes soit plus lent à cause du langage qui traite le résultat des requêtes.
Mouais, ça dépend de ce que l'on veut je comprend.
Je pourrais tenter d'expliquer, mais on va plutôt tous se mélanger loll
Ha puis enfin, je m'essaie. C'est complémentaire, vous m'avez déjà mis sur la bonne piste merci! Pour les curieux, vous pouvez continuer à lire
---------------------------
En gros, j'ai 6 tables.
Dans chaque, il y a le même nombre de lignes qui ont chacun un numéro unique, disons de 1 à 100.
Dans chaque table, il y a différentes colonnes. Donc bref, TOUT pourrait être grosso modo dans la même table, mais cette table aurait énormément de colonnes.
Je fais des conditions sur certaines colonnes de chaque tables, afin d'obtenir en bout de ligne y numéros uniques parmi les 100.
Puis, dernière étape je prend ces y valeurs et je demande de me sortir les informations x BETWEEN min(x) AND min(x)+1) associées à y.
Donc bref,le min(x) a seulement besoin de rouler sur les x qui m'intéressent et non pas tous.
C'est pour cette raison que je crois que je dois répéter mes conditions ou plutôt, je ne suis pas obligé, mais ça permet d'optimiser je crois.
Donc bref,le min(x) a seulement besoin de rouler sur les x qui m'intéressent et non pas tous.
MIN est une fonction agissant sur un ensemble de lignes. Si elle ne doit considérer que certaines lignes de ta table, alors oui, il faut re-spécifier une condition dans les WHERE du sous-SELECT
Si MySQL est bien conçu, pour deux sous-SELECTs ayant une même déclaration, il ne devrait exécuter la sous-requête qu'une seule fois (mais là il faut aller voir dans la doc comment afficher le plan d'exécution de ta requête).
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
Sauf si on fait (SELECT MIN(*) ...) + 1 pour la deuxième partie. Mais ce n'est pas recommandé par le manuel MySQL . Il faut donc voir ce qui est le plus rapide.
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
Je vais peut-être dire une bêtise, mais on pourrait très bien faire une procédure stockée, ainsi on ne fera la requête (pour le MIN et MIN+1) qu'une seule fois.
fonction MIN en SQL
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll