160
Chapitre 6 • SQL avancé
Il n’en va pas de même de la requête ci-dessous qui renvoie un résultat vide !
select NCLI
from CLIENT
where CAT = (select CAT
from CLIENT
where NCLI = 'K729')
Comme nous l’avons déjà vu dans la section 5.3.4, la raison en est que la comparaison de deux expressions dont la valeur est null renvoie unknown (voir règle cidessus). On pourrait estimer que SQL aurait pu se montrer plus conciliant (plus
intelligent), et renvoyer au moins K729, qui, de toute évidence, devrait avoir la
même valeur de CAT que lui-même ! C’est donc la règle "X = Y vaut unknown si X
ou Y vaut null" qui prévaut.
D’ailleurs, la condition CAT = CAT induira un comportement analogue : elle écartera les deux lignes litigieuses.
On peut encore ajouter à la liste des interprétations correctes, bien que contraires
à l’intuition, le fait qu’en présence de valeurs null, l’expression X < X (ou X <> X)
bien que fausse ne vaut pas false et X = X bien que vraie ne vaut pas true !
b) . . . sauf, hélas, dans certains cas
Malheureusement, les choses ne sont pas toujours aussi simples. Constituons par
exemple des groupes de clients par catégories :
select CAT, count(*)
from
CLIENT
group by CAT
Le résultat semble naturel à première vue :
Or, pour constituer le dernier groupe, il faut admettre que toutes les lignes dont CAT
= null ont même valeur de CAT, et donc qu’ici null = null. Certains SGBD
préféreront faire de chaque ligne dont CAT = null un groupe autonome, ce qui est
cette fois cohérent avec la règle de comparaison, mais peu intuitif.
Citons un autre exemple, celui d’un identifiant formé d’une colonne facultative.
Supposons que les produits d’exportation reçoivent un numéro d’agréation unique,
ce que nous traduisons par une nouvelle colonne associée à la table PRODUIT.
Puisque ce numéro ne concerne que certains produits, la colonne est déclarée facultative; ses valeurs étant uniques, on y ajoute une clause unique :
CAT
count(*)
B1
B2
C1
C2
4
4
5
1
2
Chapitre 6 • SQL avancé
Il n’en va pas de même de la requête ci-dessous qui renvoie un résultat vide !
select NCLI
from CLIENT
where CAT = (select CAT
from CLIENT
where NCLI = 'K729')
Comme nous l’avons déjà vu dans la section 5.3.4, la raison en est que la comparaison de deux expressions dont la valeur est null renvoie unknown (voir règle cidessus). On pourrait estimer que SQL aurait pu se montrer plus conciliant (plus
intelligent), et renvoyer au moins K729, qui, de toute évidence, devrait avoir la
même valeur de CAT que lui-même ! C’est donc la règle "X = Y vaut unknown si X
ou Y vaut null" qui prévaut.
D’ailleurs, la condition CAT = CAT induira un comportement analogue : elle écartera les deux lignes litigieuses.
On peut encore ajouter à la liste des interprétations correctes, bien que contraires
à l’intuition, le fait qu’en présence de valeurs null, l’expression X < X (ou X <> X)
bien que fausse ne vaut pas false et X = X bien que vraie ne vaut pas true !
b) . . . sauf, hélas, dans certains cas
Malheureusement, les choses ne sont pas toujours aussi simples. Constituons par
exemple des groupes de clients par catégories :
select CAT, count(*)
from
CLIENT
group by CAT
Le résultat semble naturel à première vue :
Or, pour constituer le dernier groupe, il faut admettre que toutes les lignes dont CAT
= null ont même valeur de CAT, et donc qu’ici null = null. Certains SGBD
préféreront faire de chaque ligne dont CAT = null un groupe autonome, ce qui est
cette fois cohérent avec la règle de comparaison, mais peu intuitif.
Citons un autre exemple, celui d’un identifiant formé d’une colonne facultative.
Supposons que les produits d’exportation reçoivent un numéro d’agréation unique,
ce que nous traduisons par une nouvelle colonne associée à la table PRODUIT.
Puisque ce numéro ne concerne que certains produits, la colonne est déclarée facultative; ses valeurs étant uniques, on y ajoute une clause unique :
CAT
count(*)
B1
B2
C1
C2
4
4
5
1
2