Valeurs NULL à l'intérieur de la clause NOT IN

Ce problème est survenu lorsque j'ai obtenu différents nombres d'enregistrements pour ce que je pensais être des requêtes identiques, l'une utilisant une not in wherecontrainte et l'autre a left join. La table dans la not incontrainte avait une valeur nulle (données incorrectes) qui a provoqué le renvoi de 0 enregistrements à cette requête. Je comprends en quelque sorte pourquoi mais je pourrais utiliser de l'aide pour bien comprendre le concept.

Pour le dire simplement, pourquoi la requête A renvoie-t-elle un résultat mais pas B?

A: select 'true' where 3 in (1, 2, 3, null)
B: select 'true' where 3 not in (1, 2, null)

C'était sur SQL Server 2005. J'ai également constaté que l'appel set ansi_nulls offobligeait B à retourner un résultat.

La requête A est identique à:

select 'true' where 3 = 1 or 3 = 2 or 3 = 3 or 3 = null

Puisque 3 = 3c'est vrai, vous obtenez un résultat.

La requête B est identique à:

select 'true' where 3 <> 1 and 3 <> 2 and 3 <> null

Quand ansi_nullsest 3 <> nullactivé , est INCONNU, donc le prédicat est évalué comme INCONNU et vous n'obtenez aucune ligne.

Quand ansi_nullsest désactivé, 3 <> nullest vrai, donc le prédicat est évalué à vrai et vous obtenez une ligne.

Chaque fois que vous utilisez NULL, vous avez vraiment affaire à une logique à trois valeurs.

Votre première requête renvoie des résultats lorsque la clause WHERE est évaluée comme suit:

    3 = 1 or 3 = 2 or 3 = 3 or 3 = null
which is:
    FALSE or FALSE or TRUE or UNKNOWN
which evaluates to 
    TRUE

Le deuxième:

    3 <> 1 and 3 <> 2 and 3 <> null
which evaluates to:
    TRUE and TRUE and UNKNOWN
which evaluates to:
    UNKNOWN

L'INCONNU n'est pas le même que FAUX, vous pouvez facilement le tester en appelant:

select 'true' where 3 <> null
select 'true' where not (3 <> null)

Les deux requêtes ne vous donneront aucun résultat

Si l'inconnu était le même que FAUX, alors en supposant que la première requête vous donnerait FAUX, la seconde devrait être évaluée comme VRAIE car elle aurait été la même que NON (FAUX).
Ce n'est pas le cas.

Il y a un très bon article sur ce sujet sur SqlServerCentral .

Tout le problème des NULL et de la logique à trois valeurs peut être un peu déroutant au début, mais il est essentiel de comprendre afin d'écrire des requêtes correctes dans TSQL

Un autre article que je recommanderais est SQL Aggregate Functions and NULL .

NOT IN renvoie 0 enregistrements par rapport à une valeur inconnue

Étant donné qu'il NULLs'agit d'un inconnu, une NOT INrequête contenant un NULLou NULLs dans la liste des valeurs possibles retournera toujours des 0enregistrements car il n'y a aucun moyen de s'assurer que la NULLvaleur n'est pas la valeur en cours de test.

La comparaison avec null n'est pas définie, sauf si vous utilisez IS NULL.

Ainsi, lors de la comparaison de 3 à NULL (requête A), il renvoie undefined.

Soit SELECT 'vrai' où 3 pouces (1,2, null) et SELECT 'vrai' où 3 pas dans (1,2, null)

produira le même résultat, car NOT (UNDEFINED) n'est toujours pas défini, mais pas TRUE

Le titre de cette question au moment de la rédaction est

Contrainte SQL NOT IN et valeurs NULL

D'après le texte de la question, il semble que le problème se produisait dans une SELECTrequête SQL DML , plutôt que dans une DDL SQL CONSTRAINT.

Cependant, compte tenu en particulier du libellé du titre, je tiens à souligner que certaines déclarations faites ici sont des déclarations potentiellement trompeuses, celles qui s'inspirent de (paraphrasant)

Lorsque le prédicat est évalué sur UNKNOWN, vous n'obtenez aucune ligne.

Bien que ce soit le cas pour SQL DML, lorsque l'on considère les contraintes, l'effet est différent.

Considérez ce tableau très simple avec deux contraintes tirées directement des prédicats de la question (et traitées dans une excellente réponse de @Brannon):

DECLARE @T TABLE 
(
 true CHAR(4) DEFAULT 'true' NOT NULL, 
 CHECK ( 3 IN (1, 2, 3, NULL )), 
 CHECK ( 3 NOT IN (1, 2, NULL ))
);

INSERT INTO @T VALUES ('true');

SELECT COUNT(*) AS tally FROM @T;

Selon la réponse de @ Brannon, la première contrainte (utilisation IN) est évaluée à VRAI et la seconde contrainte (utilisation NOT IN) est évaluée à INCONNU. Cependant , l'insert réussit! Par conséquent, dans ce cas, il n'est pas strictement correct de dire "vous n'obtenez aucune ligne" car nous avons en effet inséré une ligne en conséquence.

L'effet ci-dessus est en effet le bon en ce qui concerne la norme SQL-92. Comparez et contrastez la section suivante de la spécification SQL-92

7.6 clause where

Le résultat de est un tableau de ces lignes de T pour lesquelles le résultat de la condition de recherche est vrai.

4.10 Contraintes d'intégrité

Une contrainte de vérification de table est satisfaite si et seulement si la condition de recherche spécifiée n'est pas fausse pour une ligne d'une table.

En d'autres termes:

Dans SQL DML, les lignes sont supprimées du résultat lorsque l' WHEREévalué à INCONNU car il ne remplit pas la condition "est vrai".

Dans SQL DDL (c'est-à-dire les contraintes), les lignes ne sont pas supprimées du résultat lorsqu'elles sont évaluées à UNKNOWN car il remplit la condition "n'est pas faux".

Bien que les effets dans SQL DML et SQL DDL respectivement puissent sembler contradictoires, il y a une raison pratique de donner aux résultats INCONNUS le `` bénéfice du doute '' en leur permettant de satisfaire une contrainte (plus correctement, en leur permettant de ne pas manquer de satisfaire une contrainte) : sans ce comportement, toutes les contraintes devraient gérer explicitement les valeurs nulles et ce serait très insatisfaisant du point de vue de la conception du langage (sans parler, une bonne douleur pour les codeurs!)

ps si vous trouvez difficile de suivre une logique telle que "inconnu ne manque pas de satisfaire une contrainte" comme je suis en train de l'écrire, alors considérez que vous pouvez vous passer de tout cela simplement en évitant les colonnes nullables en SQL DDL et quoi que ce soit en SQL DML qui produit des valeurs nulles (par exemple des jointures externes)!

En A, 3 est testé pour l'égalité par rapport à chaque membre de l'ensemble, ce qui donne (FAUX, FAUX, VRAI, INCONNU). Étant donné que l'un des éléments est VRAI, la condition est VRAIE. (Il est également possible qu'un court-circuit se produise ici, donc il s'arrête en fait dès qu'il atteint le premier TRUE et n'évalue jamais 3 = NULL.)

En B, je pense qu'il évalue la condition comme NON (3 in (1,2, null)). Test 3 de l'égalité par rapport aux rendements définis (FALSE, FALSE, UNKNOWN), qui est agrégé à UNKNOWN. NOT (UNKNOWN) donne INCONNU. Donc, dans l'ensemble, la vérité de la condition est inconnue, ce qui à la fin est essentiellement traité comme FAUX.

On peut conclure des réponses ici qui NOT IN (subquery)ne traitent pas correctement les valeurs nulles et doivent être évitées en faveur de NOT EXISTS. Cependant, une telle conclusion peut être prématurée. Dans le scénario suivant, attribué à Chris Date (Database Programming and Design, Vol 2 No 9, septembre 1989), c'est NOT INqu'il gère correctement les valeurs nulles et renvoie le résultat correct, plutôt que NOT EXISTS.

Considérons un tableau sppour représenter les fournisseurs ( sno) qui sont connus pour fournir des pièces ( pno) en quantité ( qty). Le tableau contient actuellement les valeurs suivantes:

      VALUES ('S1', 'P1', NULL), 
             ('S2', 'P1', 200),
             ('S3', 'P1', 1000)

Notez que la quantité peut être annulée, c'est-à-dire pour pouvoir enregistrer le fait qu'un fournisseur est connu pour fournir des pièces même s'il n'est pas connu en quelle quantité.

La tâche consiste à trouver les fournisseurs connus qui fournissent le numéro de pièce «P1» mais pas en quantités de 1000.

Les utilisations suivantes permettent NOT INd'identifier correctement le fournisseur «S2» uniquement:

WITH sp AS 
     ( SELECT * 
         FROM ( VALUES ( 'S1', 'P1', NULL ), 
                       ( 'S2', 'P1', 200 ),
                       ( 'S3', 'P1', 1000 ) )
              AS T ( sno, pno, qty )
     )
SELECT DISTINCT spx.sno
  FROM sp spx
 WHERE spx.pno = 'P1'
       AND 1000 NOT IN (
                        SELECT spy.qty
                          FROM sp spy
                         WHERE spy.sno = spx.sno
                               AND spy.pno = 'P1'
                       );

Cependant, la requête ci-dessous utilise la même structure générale mais avec NOT EXISTSmais inclut incorrectement le fournisseur «S1» dans le résultat (c'est-à-dire pour lequel la quantité est nulle):

WITH sp AS 
     ( SELECT * 
         FROM ( VALUES ( 'S1', 'P1', NULL ), 
                       ( 'S2', 'P1', 200 ),
                       ( 'S3', 'P1', 1000 ) )
              AS T ( sno, pno, qty )
     )
SELECT DISTINCT spx.sno
  FROM sp spx
 WHERE spx.pno = 'P1'
       AND NOT EXISTS (
                       SELECT *
                         FROM sp spy
                        WHERE spy.sno = spx.sno
                              AND spy.pno = 'P1'
                              AND spy.qty = 1000
                      );

Ce NOT EXISTSn'est donc pas la balle d'argent qu'elle a pu apparaître!

Bien sûr, la source du problème est la présence de nulls, donc la «vraie» solution est d'éliminer ces nulls.

Ceci peut être réalisé (entre autres conceptions possibles) en utilisant deux tableaux:

• sp fournisseurs connus pour fournir des pièces
• spq fournisseurs connus pour fournir des pièces en quantités connues

notant qu'il devrait probablement y avoir une contrainte de clé étrangère où les spqréférences sp.

Le résultat peut ensuite être obtenu en utilisant l'opérateur relationnel «moins» (qui est le EXCEPTmot clé dans SQL standard), par exemple

WITH sp AS 
     ( SELECT * 
         FROM ( VALUES ( 'S1', 'P1' ), 
                       ( 'S2', 'P1' ),
                       ( 'S3', 'P1' ) )
              AS T ( sno, pno )
     ),
     spq AS 
     ( SELECT * 
         FROM ( VALUES ( 'S2', 'P1', 200 ),
                       ( 'S3', 'P1', 1000 ) )
              AS T ( sno, pno, qty )
     )
SELECT sno
  FROM spq
 WHERE pno = 'P1'
EXCEPT 
SELECT sno
  FROM spq
 WHERE pno = 'P1'
       AND qty = 1000;

Null signifie et absence de données, c'est-à-dire qu'elles sont inconnues, pas une valeur de données de rien. Il est très facile pour les personnes issues de la programmation de confondre cela, car dans les langages de type C, lorsque vous utilisez des pointeurs, null n'est en effet rien.

Donc dans le premier cas, 3 est en effet dans l'ensemble de (1,2,3, nul) donc vrai est retourné

Dans la seconde, cependant, vous pouvez le réduire à

sélectionnez 'vrai' où 3 pas dans (null)

Donc rien n'est retourné parce que l'analyseur ne sait rien de l'ensemble auquel vous le comparez - ce n'est pas un ensemble vide mais un ensemble inconnu. L'utilisation de (1, 2, null) n'aide pas car l'ensemble (1,2) est manifestement faux, mais vous êtes contre et inconnu, ce qui est inconnu.

SI vous voulez filtrer avec NOT IN pour une sous-requête contenant des NULL, vérifiez que non nul

SELECT blah FROM t WHERE blah NOT IN
        (SELECT someotherBlah FROM t2 WHERE someotherBlah IS NOT NULL )

c'est pour Boy:

select party_code 
from abc as a
where party_code not in (select party_code 
                         from xyz 
                         where party_code = a.party_code);

cela fonctionne indépendamment des paramètres ansi

SQL utilise une logique à trois valeurs pour les valeurs de vérité. La INrequête produit le résultat attendu:

SELECT * FROM (VALUES (1), (2)) AS tbl(col) WHERE col IN (NULL, 1)
-- returns first row

Mais l'ajout d'un NOTn'inverse pas les résultats:

SELECT * FROM (VALUES (1), (2)) AS tbl(col) WHERE NOT col IN (NULL, 1)
-- returns zero rows

En effet, la requête ci-dessus est équivalente à la suivante:

SELECT * FROM (VALUES (1), (2)) AS tbl(col) WHERE NOT (col = NULL OR col = 1)

Voici comment la clause where est évaluée:

| col | col = NULL (1) | col = 1 | col = NULL OR col = 1 | NOT (col = NULL OR col = 1) |
|-----|----------------|---------|-----------------------|-----------------------------|
| 1   | UNKNOWN        | TRUE    | TRUE                  | FALSE                       |
| 2   | UNKNOWN        | FALSE   | UNKNOWN (2)           | UNKNOWN (3)                 |

Remarquerez que:

1. La comparaison des NULLrendementsUNKNOWN
2. L' ORexpression où aucun des opérandes ne se trouve TRUEet au moins un opérande est UNKNOWNrenvoie UNKNOWN( ref )
3. L' NOTdes UNKNOWNrendements UNKNOWN( ref )

Vous pouvez étendre l'exemple ci-dessus à plus de deux valeurs (par exemple NULL, 1 et 2) mais le résultat sera le même: si l'une des valeurs est NULLalors aucune ligne ne correspondra.

cela peut également être utile pour connaître la différence logique entre la jointure, existe et dans http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx