Jai vu la requête MySQL suivante qui utilise à la fois DISTINCT et GROUP BY:
SELECT DISTINCT user_id, post_id, post_content FROM some_table GROUP BY post_id, user_id HAVING post_content LIKE "%abc%"; Voici un scénario pour accompagner la requête: chaque utilisateur a un identifiant unique, user_id, et peut publier plusieurs messages qui sont identifiés par un identifiant unique, post_id. Chaque message contiendrait du texte.
Jai trouvé cela déroutant (après être venu des bases de données Oracle) et javais les questions ci-dessous:
- Quelle est la signification de lutilisation de
GROUP BYsans effectuer dagrégation? - Quelle est limportance de changer lordre des colonnes dans
SELECTpar rapport àGROUP BY? - Que signifie omettre la troisième colonne de
GROUP BY? - Pourquoi
DISTINCTutilisé avecGROUP BY? Une opération distincte sexécute-t-elle après que tous les regroupements ont été effectués sur le résultat final ou avant?
Commentaires
Réponse
annonce 1) Anciennes bases de données mysql et lorsque vous désactivez ONLY_FULL_GROUP_BY , vous pouvez effectuer cette requête et si les post_content sont tous égaux, vous remarquerez que mysql renvoie une valeur aléatoire non déterministe .
annonce 2) rien du tout
annonce 3) programmation paresseuse et il se produit une erreur lorsque vous activez ONLY_FULL_GROUP_BY
ad 4) Non, il afficherait tous les post_content connectés à user_id, post_id similaire à addind post_content au groupe par
Comme Strawberry la déjà dit, cette requête ne « t na aucun sens
Réponse
La capacité insensée dautoriser des groupes partiels dans les anciennes versions de MyS QL, doit être lun des principaux prétendants pour la plupart des confusions dans lindustrie informatique.
Compte tenu du tableau:
CREATE TABLE t ( x int not null primary key , y int not null ); INSERT INTO t (x,y) VALUES (1,1),(1,2); La déclaration
SELECT x, y FROM t GROUP BY x pourrait signifier (1,1) ou (1,2) et MySQL retournerait aléatoirement lun dentre eux. DISTINCT na pas dimportance dans ce cas, le résultat est toujours indéterministe.
SQL92 exigeait que toutes les colonnes de la clause select (à lexception des colonnes agrégées et des constantes) fassent partie de la clause GROUP BY.
SQL99 a un peu assoupli cette restriction et nous a permis domettre les colonnes de GROUP BY qui sont fonctionnellement dépendantes des colonnes restantes. Cest-à-dire que
CREATE TABLE t ( x int not null primary key , y int not null ); SELECT x, y FROM t GROUP by x serait valide puisque y est f.d. of x
De manière assez surprenante (pour moi), la version ultérieure de MySQL est la meilleure de sa catégorie lorsquil sagit dimplémenter la version SQL99. Je ne lai pas vérifié récemment, mais quand je lai fait, MySQL a bien géré des scénarios assez compliqués, où PostgreSQL ne gérait que les plus triviaux.
Pour répondre à vos questions
1)
SELECT x, y FROM t GROUP BY x, y signifie que la combinaison de x, y est un groupe. Dans toutes les situations possibles, je peux penser que cest la même chose que:
SELECT DISTINCT x, y FROM t Puisquils sont évalués logiquement à des moments différents, il pourrait y avoir un cas dangle où ils seraient en fait différents (je ne peux pas penser à un cependant)
2) Aucun , à cet égard, il sagit dun ensemble de colonnes, il ny a donc pas dordre
3) Voir ci-dessus.
4) Lordre logique dévaluation dune requête SQL est:
FROM, JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY FETCH FIRST donc GROUP BY est censé être évalué avant DISTINCT. Je ne peux pas penser à une situation où cela aurait une importance.
Dans votre requête Je soupçonne que quelquun a obtenu des résultats confus et a essayé dobtenir un autre résultat en utilisant DISTINCT. Ils ont probablement eu de la chance (ou pas de chance) dobtenir le résultat. prévu, donc le DISTINCT est resté. Le bogue est toujours là
GROUP BYna pas du tout dimportance (sauf que dans les anciennes versions, cela impliquait le mêmeORDER BY. LeSELECTlordre na dimportance que dans la disposition des colonnes dans la sortie.