Je vois encore énormément d’erreurs à ce sujet, chez les développeurs avec qui je travaille et j’ai travaillé, mais aussi sur le forum.
Voici donc la démonstration que NULL en SQL n’est pas une valeur …
C’est très simple : exécutez la requête suivante :
1 2 3 | IF NULL = NULL PRINT 'OK' ELSE PRINT 'KO' |
Vous pensez que l’on va obtenir OK … Donc vous pensez que NULL est une valeur et c’est faux : on obtiendra KO !
Vous pouvez faire l’expérience avec n’importe quel autre opérateur arithmétique (>, >=, <, <=, <>, !=) : vous obtiendrez toujours KO
Ceci prouve que NULL n’est pas une valeur : en SQL, c’est un marqueur qui signifie l’absence de valeur.
C’est d’ailleurs la raison pour laquelle en SQL, on écrit IS NULL dans un prédicat (WHERE ou JOIN), et non pas = NULL.
En revanche, dans un langage comme Java ou C#, null == null est effectivement vrai.
En effet, beaucoup de langages évaluent les expressions logiques suivant deux valeurs : true ou false.
Mais en SQL, un prédicat et évalué comme étant TRUE, FALSE ou UNKNOWN.
De la même façon, toute autre opération (NULL [operateur_arithmétique] [valeur]), peu importe le type de [valeur], retourne toujours NULL :
- NULL + 4
- NULL + ‘uneChaine’
- REPLACE(uneChaineNULL, ‘qqch’, ‘_qqch’)
Enfin, NULL est traité différemment par les différents opérateurs que l’implémentation SQL Server de SQL propose :
- Les filtres de requête (ON d’une jointure, WHERE (et AND qui suivent) et HAVING) évalueront NULL comme ne vérifiant pas le prédicat
- Une contrainte CHECK évaluera NULL comme vérifiant le prédicat
- Une contrainte UNIQUE prend NULL comme une valeur, ce qui est totalement faux
- Une opération avec les opérateurs d’ensembles UNION, EXCEPT et INTERSECT traite NULL comme une valeur, ce qui est également faux
- GROUP BY groupe tous les NULL dans un groupe distinct
- ORDER BY trie le NULL ensemble
- La fonction COUNT() tient compte de NULL
- Les autres fonctions d’agrégation n’en tiennent pas compte
Attention à NULL 
ElSüket