Il y a une question sur la fonction d'agrégat de Count () de MySQL () qui empêche la tête du temps. J'aimerais avoir une explication sur la raison pour laquelle cela fonctionne comme ça.
Lorsque j'ai commencé à travailler avec MySQL, j'ai rapidement appris que son compte (condition) semble seulement fonctionner correctement si la condition contient également un ou des nuls à la fin. En cas de conditions de comptage plus compliquées, il s'agissait d'un processus empirique de savoir où le mettre exactement. Dans MSSQL, vous n'avez pas besoin de cela ou de NULL pour obtenir des résultats appropriés. Je voudrais donc connaître l'explication pour cela. Donc, voici un exemple.
permet de disposer d'une table très basique avec la structure et des données suivantes: scénario: je voudrais compter comment Beaucoup de lignes que j'ai où la valeur = 4. Une solution évidente serait de filtrer pour cela à l'aide d'un nombre et de compter (*) mais je suis intéressé par une solution basée sur le compte (condition). Donc, la solution qui me vient à l'esprit est la suivante: Le résultat est 10. Ceci est évidemment faux. deuxième tentative avec ou null: Le résultat est 3. Il est correct. Quelqu'un peut-il expliquer la logique derrière cela? S'agit-il de quelques insectes dans MySQL ou y a-t-il une explication logique pourquoi j'ai besoin d'ajouter ce étrange ou null à la fin de la condition de comptage pour obtenir le résultat correct?
5 Réponses :
comptage (expression) compte le nombre de lignes pour lesquelles l'expression n'est pas nulle. L'expression valeur = 4 code> est seulement null si la valeur est null, sinon elle est vraie (1) ou false (0), toutes deux comptées. SELECT
SUM(a>b) AS foo,
SUM(b>c) AS bar,
COUNT(*) AS total_rows
FROM test
Um, somme (a> b) peut toujours être remplacé par compter (A> b ou null) , ne peut-il pas? Donc, je ne vois pas vraiment comment somme () mieux convient ici que dans l'exemple de l'OP.
Eh bien, pour une chose, la somme est moins à taper. Comme je l'ai dit, cela ne donne pas grand chose dans l'exemple spécifique que l'OP a donné - une clause où peut être utilisé à la place. Mais cela peut être utile dans d'autres situations.
Dans votre expression de cas Mais je suis intéressé par une solution basée sur le compte (condition).
Le comptage Count () La fonction accepte un argument, qui est traité comme null ou non null . S'il est pas null - alors il incrémente la valeur, et ne rien faire autrement.
valeur = 4 est soit true ou false , évidemment tous les deux true et faux ne sont pas nuls, c'est pourquoi vous obtenez 10.
-Based sera toujours plus lent (beaucoup plus lent), car il provoquera une table entier et une comparaison itérative de chaque valeur.
Vous avez répondu la moitié de la question .. incomplète était le mot que j'étais après
Je vous suggérerais que la syntaxe plus standard se déplace mieux entre différents moteurs de base de données et donnera toujours le résultat correct. est la syntaxe que vous avez utilisée une variante MySQL?
C'est parce que le nombre (expression) compte les valeurs. Dans la théorie SQL, NULL est un état, pas une valeur et donc n'est pas compté. NULL est un état qui signifie que la valeur du champ est inconnue.
Maintenant, lorsque vous écrivez "valeur = 4", cela évalue à Booléan True ou False. Depuis que les valeurs vraies et fausses sont des valeurs, le résultat est de 10.
Lorsque vous ajoutez "ou NULL", vous avez réellement "vrai ou null" et "faux ou null". Maintenant, "TRUE OU NULL" évalue à vrai, tandis que "FAUX ou NULL" évalue à NULL. Ainsi, le résultat est 3, car vous n'avez que 3 valeurs (et sept états nuls).
Ceci devrait révéler tout
SELECT sum(value=4) FROM test
+1 pour orthographier la table de vérité des opérations booléennes avec null
Et +1 pour celui-ci pour expliquer pourquoi il se comporte comme cela, et les cas d'utilisation où il suffit d'utiliser où est inadéquat.
Une bonne réponse, ça explique tout. Je serais intéressant de savoir pourquoi ils ont décidé de la mettre en œuvre de cette façon, par ex. Le nombre basé sur est NULL / n'est pas nul au lieu de la véritable approche beaucoup plus courante / fausse.
@Codetwice Vous pouvez avoir sur le visage. Le nombre (booléen) est en fait moins commun. SQL Server ne vous laissez même pas utiliser les expressions booléennes seules (bit! = Booléen). Plus de gens comptent des colonnes (existence de valeur == [pas] null) plutôt que d'évaluer une condition.
En fait, cela ressemble à un bogue dans MSSQL.
@Milan - ce serait si nous étaient discuter de MSSQL
@Richard, avez-vous même pris la peine de lire la question? Il parle de MSSQL à droite et MySQL est probablement faux.