Discussion :

[skuatamad]

Bon ok j'avais zapé le DISTINCT donc on oublie l'histoire des doublons.
Sinon ça ne veut pas dire qu'il n' y a pas de NULL

Mais je vais arrêter d'être chiant , donc oriente toi vers des recherches de bug concernant ta version. En cherchant méga vite fait j'ai trouvé çà :
http://forums.mysql.com/read.php?121,143298,143298

STP tiens nous au courant, ça peut en intéresser plus d'un.

[olibara]

Salut

Bon pour te débarasser de la petite bete qui te trotte en tete je peux t'assurer qu'il n'y a pas de NULL car je ne permet pas de NULL sur AddrID dans ces tables !


Je viens d'upgrader en 5.1
Meme problème
Petite info je suis en MyIsam et pas InnoDB

[olibara]

Pour celui qui veut essayer, je fais deux petite tables, une avec 2256 records l'autre avec 117

Et chacun peut essayer dans son environnement !
On verra bien si c'est
- structurel
- ou un bug de version(s)
- ou lié a l'environnement !

[Antoun]

Pour celui qui veut essayer, je fais deux petite tables, une avec 2256 records l'autre avec 117

je n'aurai pas le temps ce soir, mais je suis preneur !

[skuatamad]

Bon pour te débarasser de la petite bete qui te trotte en tete je peux t'assurer qu'il n'y a pas de NULL car je ne permet pas de NULL sur AddrID dans ces tables !

Merci, St thomas est satisfait
Et +1 pour le jeu de test.

[olibara]

Ouf !

J'ai ramé une bonne partie de la journée a refaire fonctionner Navicat qui plantait apres l'upgrade MySql 5.1

Il m'aura couté cher ce Not In


Voici donc deux tables permettant de facilement reproduire l'effet null du not in

Et le query qui va avec

Code :

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

1
2
3
4
5
select distinct 
adr.addrid
from adr
where
(adr.addrid  not  in (select addrid from okx))

[Antoun]

Merci pour les tables de test !

Pour l'anecdote, il y a bien un NULL sur la première ligne de okx, où addrid n'est pas en NOT NULL.

Sur le fond, il semble bien que tu mettes en évidence un bug du NOT IN, qui persiste encore dans la version 5.1.19.

[olibara]

Caramba !

Tu a raison j'ai laissé les ALLOW NULL dans la table OK, et je n'avais pas vu ce NULL

Sans lui ca marche bien
Donc le bug vient bien de ce null

Sur le fond, il semble bien que tu mettes en évidence un bug du NOT IN, qui persiste encore dans la version 5.1.19

Je dirais meme 5.1.28 !!

[Antoun]

Sans lui ca marche bien
Donc le bug vient bien de ce null

Effectivement. Bravo pour avoir trouvé le contournement, je n'avais même pas pensé à tester sans le NULL

Tu es mûr pour devenir crashtesteur chez MySQL AB

c'est pour toi ?

[olibara]

Mmmouais !

Résolu en esperant que les Crashmakers de Mysql AB liront un jour ce post

[olibara]

En fait dans le cas présent le NULL agit comme un Joker !

C'est la valeur magique qui represente TOUT
J'en connais qui parviendront a debattre une logique sur le sujet

[Antoun]

Résolu en esperant que les Crashmakers de Mysql AB liront un jour ce post

Il ne tient qu'à toi d'aller poster le truc sur bugs.mysql.com.

En fait dans le cas présent le NULL agit comme un Joker !

C'est la valeur magique qui represente TOUT
J'en connais qui parviendront a debattre une logique sur le sujet

'farpaitement ! j'étais justement en train de vérifier les tables de vérité dans mon Celko (Data and database concepts in practice, que je recommande à tous)

Donc, en termes de logique tri-valuée (TRUE / FALSE / UNKNOWN), Valeur IN (NULL) est UNKNOWN, et donc Valeur NOT IN (NULL) devrait être UNKNOWN aussi. Le bug semble indiquer que, dans ce cas, MySQL interprète (à tort) le Valeur NOT IN (NULL) comme TRUE et non UNKNOWN.

[olibara]

Je t'avais dis que certains parviendront a prétendre que c'est logique !!


http://bugs.mysql.com/bug.php?id=40035

http://bugs.mysql.com/bug.php?id=40035

[Antoun]

Je t'avais dis que certains parviendront a prétendre que c'est logique !!


http://bugs.mysql.com/bug.php?id=40035

http://bugs.mysql.com/bug.php?id=40035

Non, le gars se plaint que le résultat est NULL (donc UNKNOWN), alors que c'est logique que ce soit NULL. Ton bug est que ce n'est pas NULL mais TRUE.

[olibara]

Salut

Bon le gars c'est moi !

J'ai probablement mal exprimé la chose

TableA contient 2000 ID
TableB contient 100 ID

Quand je fais

Code :

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

1
2
3
4
5
select 
ID
From tableA
where ID NOT IN 
(Select ID from TableB)

Je recoit 1900 ID : normal

Si j'ajoute un ID NULL dans table B et que je fais le meme select, le résultat et NULL : pas de row : NADA : 0 records : rien du tout

Je sais pas comment le dire pour qu'on me comprenne

[Antoun]

Salut

Bon le gars c'est moi !

Enchanté !

J'ai probablement mal exprimé la chose

Non, en fait c'est lui qui a raison et moi qui déconne

Donc, en termes de logique tri-valuée (TRUE / FALSE / UNKNOWN), Valeur IN (NULL) est UNKNOWN, et donc Valeur NOT IN (NULL) devrait être UNKNOWN aussi.

J'ai bon jusque-là...

Le bug semble indiquer que, dans ce cas, MySQL interprète (à tort) le Valeur NOT IN (NULL) comme TRUE et non UNKNOWN.

Là par contre, je m'emmêle les pinceaux. Que tu obtiennes un résultat vide indique que le NOT IN n'est pas TRUE (en l'occurrence, qu'il est UNKNOWN).

Dit plus simplement :

En fait dans le cas présent le NULL agit comme un Joker !

C'est la valeur magique qui represente TOUT

Je peux aussi te le dire comme ça :

Le NULL représente l'inconnu. Quand tu demandes "sors-moi les ID qui sont dans NULL", un SGBD te réponds "je n'en sais rien". Quand tu demandes "sors-moi les ID qui ne sont pas dans NULL", il te répond aussi "je n'en sais rien".

Pour plus de détails sur les points vicieux du NULL, cf http://sqlpro.developpez.com/cours/null/. Je vais lui suggérer d'ajouter un paragraphe "NULL et IN" !

[skuatamad]

Bon j'arrive un peu tard mais j'ai pas trop su exploiter immédiatement les fichiers .

Juste pour compléter un peu, le comportement de IN et NOT IN n'est pas tout à fait identique fasse au NULL.

IN(NULL) et NOT IN(NULL) ne renvoient rien et c'est normal.
IN(1,NULL,2) marche bien, si ce n'est que les données NULL ne sont pas renvoyées, mais c'est normal.
Par contre NOT IN(1,NULL,2) ne renvoie toujours rien, ce qui peut surprendre mais comme les SGBDs se comportent tous de la même manière ça ne peut donc pas être considéré comme un bug.

Ma question serait plutôt pourquoi IN(1,NULL,2) renvoie 1 et 2, le SGBD pourrait considérer que la présence d'inconnu dans la clause l'empêche de résoudre la requête.
Mais mes connaissances en logique sont plus que limitées... le Celko tu dis, je pense que ça va être mon prochain achat

[Antoun]

Ma question serait plutôt pourquoi IN(1,NULL,2) renvoie 1 et 2, le SGBD pourrait considérer que la présence d'inconnu dans la clause l'empêche de résoudre la requête.

Non, il sait qu'il y a 1 et 2, donc le résultat est TRUE quel que soit le contenu du NULL.

Dans le même ordre d'idées, les tables de vérité de la logique tri-valuée (établies par Łukasiewicz) disent que TRUE OR UNKNOW est TRUE.

[Antoun]

Mais mes connaissances en logique sont plus que limitées... le Celko tu dis, je pense que ça va être mon prochain achat

Ce bouquin ne contient pas de grande révélation foudroyante, mais il est très bien pour faire le point sur plein de petits détails de ce genre.

[skuatamad]

Effectivement, j'avais oublié la correspondance en expression logique des clause IN et NOT IN :
x IN(1,NULL,2)<=>x=1 OR x=NULL OR x=2
x NOT IN(1,NULL,2)<=>x!=1 AND x!=NULL AND x!=2
Et forcément avec des AND le résultat est UNKNOWN.