Discussion :

[Sve@r]

Bonjour à tous

Pardon de poser cette question très bas niveau mais je me demande pourquoi le "select" ne traite pas le null comme la logique semblerait (enfin ma façon de voir cette logique)

Imaginons une table des personnes contenant nom (not null), prenom (not null) et ville. Le champ "ville" peut donc être null.
Cette table contient 3 infos

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
'toto', 'alfred', 'paris'
'titi', 'jean', 'paris'
'tutu', 'paul', null

Si je demande select nom from personne where ville='paris' je n'obtiens que "toto" et "titi". Pourtant rien n'indique que "tutu" n'est pas sur Paris lui aussi, absence d'info n'est pas preuve d'absence.
Si je veux tutu, je dois écrire select nom from personne where ville='paris' or ville is null.

Et là je ne sais pas trop comment formuler ma question. En gros, c'est "qu'est-ce qui a poussé les concepteurs SQL à adopter cette politique" ou plutôt "est-ce que ma façon de considérer ce manque d'information est la bonne" ?

Ou peut-être y a-t-il une option particulière qui permettrait au select de récupérer aussi la ligne quand le champ demandé est null (en dehors de rajouter ce or ville is null dans le where)...

Voilà, merci à tous.

[Séb.]

3 états logiques TRUE / FALSE / UNKNOW impliquent une arithmétique particulière.
C'est un des inconvénients du marqueur NULL que les puristes abhorrent.

personne	nom	prenom	ville
		---	------	-----
		toto	alfred	paris
		titi	jean	paris
		tutu	paul	<null>

select nom from personne where ville = 'paris'

Que cela ne retourne pas "tutu" ne me choque pas puisque ville n'est pas strictement égal à "paris" (résultat du test ville = 'Paris' pour ville valant NULL => "UNKNOW") et WHERE ne conserve que les lignes évaluées TRUE.

À mon sens le plus étonnant au 1er abord serait plutôt :

select nom from personne where ville <> 'paris'

... qui ne donnerait toujours pas "tutu".

Avec MySQL pour obtenir les lignes dont "ville" ne vaut pas "paris", NULL y compris, on pourrait faire :

select nom from personne where not ville <=> 'paris' -- NULL-safe equal

Avec PostgreSQL il y a "IS [NOT] DISTINCT FROM"


Un article sur la 3VL (three-valued-logic) SQL => https://modern-sql.com/concept/three-valued-logic

[Sve@r]

C'est un des inconvénients du marqueur NULL que les puristes abhorrent.

Intéressant. Et comment (annexe) font les puristes pour signifier "je n'ai pas cette information" ? Rien contre toi je t'assure, très gentil à toi de venir me conseiller, mais voilà, quand on me dit "on n'utilise pas ceci" il faut rajouter ensuite "comment faire pour"...

Que cela ne retourne pas "tutu" ne me choque pas puisque ville n'est pas strictement égal à "paris" (résultat du test ville = 'Paris' pour ville valant NULL => "UNKNOW") et WHERE ne conserve que les lignes évaluées TRUE.

Oui effectivement, tu traduis là la vision booléenne pure. Mais cette vision voit là ses limites.

À mon sens le plus étonnant au 1er abord serait plutôt :

select nom from personne where ville <> 'paris'

... qui ne donnerait toujours pas "tutu".

Ah oui joli exemple (j'ai testé)

Avec PostgreSQL il y a "IS [NOT] DISTINCT FROM"

Il y a effectivement du mieux. J'ai en effet essayé select * from personne where ville is distinct from 'Paris' et j'obtiens bien "tutu" (ville inconnue donc effectivement peut-être pas Paris). Mais en inversant select * from personne where ville is not distinct from 'Paris' je n'obtiens à nouveau que "toto" et "titi". Il y a là une certaine forme de logique je n'en disconviens pas (ce second résultat étant le tout ôté du premier) mais cette logique se heurte à l'autre (la ligne dont la ville est inconnue peut donc tout à fait correspondre à ce qu'on cherche)

Enfin bon c'est juste histoire de causer, si on peut pas je fais avec. Un grand merci de t'être intéressé à mon sujet et de tes conseils

PS: super ton article. J'aime beaucoup les exemples

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
NULL = 1
NULL <> 1
NULL > 1
NULL = NULL

[Séb.]

Et comment (annexe) font les puristes pour signifier "je n'ai pas cette information" ? Rien contre toi je t'assure, très gentil à toi de venir me conseiller, mais voilà, quand on me dit "on n'utilise pas ceci" il faut rajouter ensuite "comment faire pour"...

Comment font les puristes du relationnel ? Ils utilisent des valeurs drapeaux.
Ici, sans NULL autorisé, on pourrait convenir d'un drapeau valant "<inconnu>" ou "" (chaîne vide).

personne	nom	prenom	ville
		---	------	-----
		toto	alfred	paris
		titi	jean	paris
		tutu	paul	<inconnu>

Si plusieurs tables on peut imaginer un code commune "00000" :

ville		code	nom
		-----	---
		00000	<inconnu>
		75000	paris
	
personne	nom	prenom	ville
		---	------	-----
		toto	alfred	75000
		titi	jean	75000
		tutu	paul	00000

Oui effectivement, tu traduis là la vision booléenne pure. Mais cette vision voit là ses limites.

Je traduis le comportement de l'opérateur "=" et de la clause WHERE tels que définis par SQL.
Les opérateurs "IS" et "<=>" se comportent différemment avec NULL.

Tu peux aussi jouer avec COALESCE() :

select nom
from personne
-- Si ville est NULL alors retourne "paris"
where coalesce(ville, 'paris') = 'paris'

Qui correspond à :

select nom from personne where ville = 'paris' or ville is null

Mais l'intention est moins claire, et je ne garantis rien sur les perfs.

[Sve@r]

Comment font les puristes du relationnel ? Ils utilisent des valeurs drapeaux.
Ici, sans NULL autorisé, on pourrait convenir d'un drapeau valant "<inconnu>" ou "" (chaîne vide).

Ah oui, tout simplement. Ben si c'est ça leur mentalité... Parce que "null" c'est déjà un drapeau, drapeau qui, en plus, peut subir la contrainte "unique". Deux lignes ont parfaitement le droit d'avoir toutes deux "null" dans la même colonne, même si cette colonne est tagguée "unique". Mais elles ne peuvent pas avoir le même drapeau. Donc ils virent un drapeau déjà existant et bien défini pour créer à la place le leur à moitié foireux. Bien content de ne pas être débilepuriste

Tu peux aussi jouer avec COALESCE() :

select nom
from personne
-- Si ville est NULL alors retourne "paris"
where coalesce(ville, 'paris') = 'paris'

Qui correspond à :

select nom from personne where ville = 'paris' or ville is null

Ah ok, testé. Bon ben un grand merci de tes éclaircissements bien sympathiques

[SQLpro]

Le NULL résulte de la théorie générale des mathématiques basées sur la logique. Le support de tout objet mathématique, et ce qui a permis de construire toutes les mathématiques, sont les règles de logique dont les principes sont les suivants :
Un prédicat (une expression logique) ne peut être évaluée qu'à :

• VRAI : le prédicat est vrai, par exemple "toutes les journées compte 24 heures"
• FAUX : le prédicat est faux, par exemple "tous les mois comptent 30 jours"
• inconnu, indécidable... : "je ment"

Pour ce dernier cas, Franck Edgar CODD, inventeur des SGBDR qui sont eux aussi une théorie mathématique, a décidé d'introduire un seul marqueur, le NULL, contrairement aux mathématiques générales qui peuvent considérer différents marqueurs : futur, passé, +∞, -∞, +ε, -ε, ∅...

Ce dernier symbole étant le plus proche du NULL... Mais comme on ne sait pas pourquoi c'est NULL dans certains cas la "valeur" pourrait être symbolisée autrement. Par exemple dans le cas d'une date de décès non encore connue, dans le futur (on est certain q"elle va exister, mais on le la connais pas actuellement).

Voici ce que je dis dans un ouvrage à paraître sur le SQL...



A +

[escartefigue]

Pour le cas particulier des dates de fin ou de décès, on utilise souvent la valeur par défaut '9999-12-31' appliquée dans le DDL pour simplifier les tables de décision.

Mais, il faut bien avoir à l'esprit que stricto-sensu, '9999-12-31' signifie qu'on sait que la date de fin n'est pas atteinte, alors que le marqueur null signifie qu'on ignore tout concernant cette date. Nuance non négligeable.

[Sve@r]

Le problème particulier de la date de fin illustre une autre notion : une base de données n'est pas statique, elle change, elle évolue dans le temps. Dans une gestion de stocks, on a des produits qui sont vendus (leur nombre diminue) et qui sont réapprovisionés (leur nombre augmente). Les prix aussi varient (enfin eux ils ne diminuent pas, d'ailleurs tous les mois les proprios des grands magasins exécutent avec joie l'ordre sql update stock set prix_vente = prix_vente * 1.1...).
La date de décès fait partie de cette évolution. La personne est titulaire d'une date de décès mais cette date n'est pas encore connue. Mais un jour elle l'est et la base évolue.

Le marqueur '9999-12-31' (ça me rappelle le marqueur '31-12-99' inscrit par les programmeurs COBOL dans leurs fichiers et qui a amené certains informaticiens (je dirai pas qui mais indice, ce n'était pas des linuxiens) à penser que leur OS allait imploser à cette date ) me semble correspondre à ce que j'ai décrié avant hier quand je parlais de remplacer un marqueur établi et qui a certains avantages par un autre plus bancal. Utiliser un marqueur particulier pour empêcher un champ d'être null...

1. ne changera pas le souci de ma requête (je veux ceux nés à Paris, un simple select where ville = 'Paris' ne me sortira pas ceux qui ont ce marqueur particulier et qui sont peut-être nés à Paris)
2. ne permettra plus à la colonne d'avoir la qualité "unique"

... sans compter les soucis que le texte de SQLPro me suggère. Par exemple si le null n'est pas indexable, il n'est donc pas indexé. Or mettre un marqueur autre sera, lui, indexable et indexé mais indexé pour rien.

Perso je ne suis pas contre le null, je trouve l'idée bien pensée et l'évolution des règles booléennes qui le prennent en compte (montrées dans le lien donné par Séb.) le sont aussi. Ma question était juste sur "comment bien le prendre en compte".

[SQLpro]

Certains SGBDR ont pensé à indexer le NULL dès le départ. Ce fut le cas de Sybase SQL Server (devenu ASE du côté Sybase et SQL Server du côté Microsoft). D'autre ne l'ont pas fait pendant très longtemps (Oracle Database en particulier).

Le problème est qu'en cas d'index ou de clé alternative nullable, il devrait y avoir pluralité de NULLs...

Il y a bien eu une discussion pour mettre dans le langage de manipulation des données tout un tas de marqueurs... Mais la mathématique des opérateurs et table de vérité devient rapidement extrêmement complexe dont peu indexable....

Déjà que lorsque l'on pose des questions du genre :

• NULL ou VRAI = ?
• NULL et FAUX = ?

La plupart des développeurs se trompent... Alors imaginer une requête du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-∞ +∞ +0 +ε -ε = ???

A +

[Sve@r]

Déjà que lorsque l'on pose des questions du genre :

• NULL ou VRAI = ?
• NULL et FAUX = ?

Il y a un moyen mnémotechnique pour se rappeler. Puisque dans la table du "et" c'est le faux qui a priorité, il conserve sa priorité aussi sur null => null et faux = faux.
Et pour le "ou" puisque c'est le vrai qui a priorité, même règle => null ou vrai = vrai.
Et pour tout le reste (null et vrai, null ou faux) c'est null. Enfin c'est comme ça que je fais pour m'en rappeler.

[SQLpro]

Il y a un moyen mnémotechnique pour se rappeler. Puisque dans la table du "et" c'est le faux qui a priorité, il conserve sa priorité aussi sur null => null et faux = faux.
Et pour le "ou" puisque c'est le vrai qui a priorité, même règle => null ou vrai = vrai.
Et pour tout le reste (null et vrai, null ou faux) c'est null. Enfin c'est comme ça que je fais pour m'en rappeler.

Je disais que la plupart des développeurs tombent dans le panneau et c'est ton cas !

En effet quand tu dis que null et faux = faux c'est faux ! En effet null et faux donne INCONNU ce qui n'est pas la même chose que faux ...
Si tu fais maintenant NON (null et faux) si tu avait raison, cela devrait donner VRAI.... Mais cela donne toujours INCONNU (UNKNOWN)...

Démo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT 1
WHERE  NULL = 1 AND 1 = 1
 
SELECT 1
WHERE  NOT(NULL = 1 AND 1 = 1)

Ces deux requêtes ne renvoient jamais rien...

En fait les développeurs oublient systématiquement la logique trois état : VRAI, FAUX, INCONNU !!!

A +

[Sve@r]

Je disais que la plupart des développeurs tombent dans le panneau et c'est ton cas !

Voyez vous ça !

En effet quand tu dis que null et faux = faux c'est faux ! En effet null et faux donne INCONNU ce qui n'est pas la même chose que faux ...

Voici quelques exemples de tables de vérité que l'on peut trouver sur le net...

Image trouvée ici : https://learn.microsoft.com/fr-fr/do...ng-null-values


Image trouvée ici : https://www.google.fr/imgres?imgurl=...AAAAB0AAAAAEBA

C'est aussi détaillé dans le lien de Séb. (fantastique ce lien, m'a beaucoup aidé )

"and" connections are false as soon as any operand is false.

A moi ça me semble assez clair...

Si tu fais maintenant NON (null et faux) si tu avait raison, cela devrait donner VRAI.... Mais cela donne toujours INCONNU (UNKNOWN)...

Ah bon...

Sais pas trop quoi penser. Peut-être que "t" pour toi ça veut dire "inconnu" tu me diras...

Démo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT 1
WHERE  NULL = 1 AND 1 = 1
 
SELECT 1
WHERE  NOT(NULL = 1 AND 1 = 1)

Ces deux requêtes ne renvoient jamais rien...

Oui enfin tu nous as fait là une vraie démo de noob. Tu aurais dû rajouter des jointures histoire de la complexifier encore un peu plus.
Peux pas demander simplement select null and false puisque c'est ça que tu veux démontrer ?
Mais surtout, puisqu'il est question de "null et faux" pourquoi ta démo est une requête "null et vrai" ? 1 = 1 est vrai il me semble, non ?

A +

Ouais voilà, A+.

[Séb.]

mysql> select not null, null and true, null and false, null or true, null or false;
+----------+---------------+----------------+--------------+---------------+
| not null | null and true | null and false | null or true | null or false |
+----------+---------------+----------------+--------------+---------------+
|     NULL |          NULL |              0 |            1 |          NULL |
+----------+---------------+----------------+--------------+---------------+
1 row in set (0.00 sec)

Mnémotechnique :
null and true => Le résultat diffère si NULL est TRUE ou FALSE => Résultat inconnu, soit NULL
null and false => Que NULL soit TRUE ou FALSE, le résultat serait FALSE => Résultat FALSE
null or true => Que NULL soit TRUE ou FALSE, le résultat serait TRUE => Résultat TRUE
null or false => Le résultat diffère si NULL est TRUE ou FALSE => Résultat inconnu, soit NULL

Mais tout le monde s'embrouille toujours, surtout quand du NOT arrive
Le mieux est d'éviter NULL

[Sve@r]

Mnémotechnique :

Je préfère le mien:

• dans le "and" de Boole, le False a priorité donc il la conserve sur le NULL. False and NULL = False
• dans le "or" de Boole, le True a priorité donc il la conserve sur le NULL. True or NULL = True
• pour les autres situations (NULL and True, NULL or False) c'est NULL

C'est le même évidemment, mais formulé différemment (pas besoin d'hypothèses style "que null soit True ou False ce serait...")

[SQLpro]

Voyez vous ça !

Voici quelques exemples de tables de vérité que l'on peut trouver sur le net...

Tu t'es encore gouré !!!

Errare humanum est... Perseverare diabolicum !

En effet dans mes requêtes, je teste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT 1
WHERE  NULL  = 1  AND  1  = 1
       [UNKNOWN]  AND  [VRAI] 
 
SELECT 1
WHERE  NOT ( NULL  = 1  AND  1  = 1 )
       NOT ( [UNKNOWN]  AND  [VRAI] )

Or toi tu regardes FALSE et UNKNOWN !



A +

[Sve@r]

Déjà que lorsque l'on pose des questions du genre :

• NULL ou VRAI = ?
• NULL et FAUX = ?

En effet quand tu dis que null et faux = faux c'est faux ! En effet null et faux donne INCONNU ce qui n'est pas la même chose que faux ...
Si tu fais maintenant NON (null et faux) si tu avait raison, cela devrait donner VRAI.... Mais cela donne toujours INCONNU (UNKNOWN)...

Or toi tu regardes FALSE et UNKNOWN !

Ben oui, bien évidemment que je regarde False et Null. Tu ne te souviens pas que c'était de "null et faux" dont j'avais parlé au départ ??? C'était pourtant le point de départ de ton discours !!!

En effet dans mes requêtes, je teste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT 1
WHERE  NULL  = 1  AND  1  = 1
       [UNKNOWN]  AND  [VRAI] 
 
SELECT 1
WHERE  NOT ( NULL  = 1  AND  1  = 1 )
       NOT ( [UNKNOWN]  AND  [VRAI] )

Ben oui, et je me demande bien pourquoi (et j'en ai déjà fait la remarque). Tu es parti de "null et faux" puis tu as tournicoté ça et noyé le poisson dans tous les sens pour presque en arriver à me faire croire qu'il s'agit de "null et vrai". Mais tu pourras lire tous mes posts, tu constateras que moi j'ai toujours parlé de "null et faux"...

[vanagreg]

SQLPro, tu es de mauvaise foi ici, c'est toi qui t'es trompé. Dans ton exemple tu testes "null et vrai". J'ai relu les réponses de Sve@r et il a bien parlé de "null et faux". ça parait évident que le résultat est faux. Vu que l'un des 2 prédicats est faux, on s'en fout du null vu que le résultat sera faux de toute façon.

Dans Oracle (le type booléen ne sera disponible en SQL qu'à partir de la version 23c, donc je teste avec la clause WHERE c'est pareil) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select * 
from dual
where 1 = null and 1 = 0;
 
--> rien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select * 
from dual
where not (1 = null and 1 = 0);
 
DUMMY
X

[escartefigue]

Vu que l'un des 2 prédicats est faux, on s'en fout du null vu que le résultat sera faux de toute façon.

C'est ça, inutile de se faire des nœuds au cerveau : avec l'opérateur AND, si l'un des opérandes est FAUX alors le résultat est FAUX, quelle que soit la valeur des autres opérandes

[Sve@r]

inutile de se faire des nœuds au cerveau

Le plus malheureux c'est que c'est sur une remarque analogue qui reprenait la même idée que l'autre matuvu infatué est venu sans raison me prendre la tête en citant Saint Augustin(*) sans même avoir l'élémentaire politesse d'au moins lire ce que j'avais écrit (et en plus, en oubliant visiblement ce que lui avait écrit et en se contredisant alors lui-même) !!!

(*): ça m'a d'ailleurs fait penser à une autre histoire plus ancienne à base de paille, de poutre, de l'oeil du voisin tout ça quoi...