Valores NULL dentro da cláusula NOT IN

Esse problema surgiu quando obtive diferentes contagens de registros para o que eu pensava serem consultas idênticas, uma usando uma not in whererestrição e a outra a left join. A tabela na not inrestrição tinha um valor nulo (dados inválidos) que fazia com que a consulta retornasse uma contagem de 0 registros. Eu meio que entendo o porquê, mas eu poderia usar alguma ajuda para entender completamente o conceito.

Para simplificar, por que a consulta A retorna um resultado, mas B não?

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

Isso foi no SQL Server 2005. Também descobri que a chamada set ansi_nulls offfaz com que B retorne um resultado.

A consulta A é igual a:

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

Como 3 = 3é verdade, você obtém um resultado.

A consulta B é igual a:

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

Quando ansi_nullsestá 3 <> nullativado , é DESCONHECIDO, portanto, o predicado é avaliado como DESCONHECIDO, e você não recebe nenhuma linha.

Quando ansi_nullsdesativado, 3 <> nullé verdadeiro; portanto, o predicado é avaliado como verdadeiro e você obtém uma linha.

Sempre que você usa NULL, está realmente lidando com uma lógica de três valores.

Sua primeira consulta retorna resultados à medida que a cláusula WHERE é avaliada para:

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

O segundo:

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

O DESCONHECIDO não é o mesmo que FALSO, você pode testá-lo facilmente chamando:

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

Ambas as consultas não fornecerão resultados

Se UNKNOWN fosse o mesmo que FALSE, assumindo que a primeira consulta lhe forneceria FALSE, a segunda teria que ser avaliada como TRUE, pois teria sido a mesma que NOT (FALSE).
Esse não é o caso.

Há um artigo muito bom sobre esse assunto no SqlServerCentral .

Toda a questão dos NULLs e da lógica de três valores pode ser um pouco confusa no começo, mas é essencial entender para escrever consultas corretas no TSQL

Outro artigo que eu recomendaria é SQL Aggregate Functions e NULL .

NOT IN retorna 0 registros quando comparado a um valor desconhecido

Como NULLé desconhecido, uma NOT INconsulta que contenha a NULLou NULLs na lista de valores possíveis sempre retornará 0registros, pois não há como garantir que o NULLvalor não seja o valor que está sendo testado.

Comparar com nulo é indefinido, a menos que você use IS NULL.

Portanto, ao comparar 3 com NULL (consulta A), ele retorna indefinido.

Ou seja, SELECT 'true' em que 3 pol (1,2, nulo) e SELECT 'true' em que 3 pol (1,2, nulo)

produzirá o mesmo resultado, pois NOT (UNDEFINED) ainda está indefinido, mas não é TRUE

O título desta pergunta no momento da redação deste artigo é

Restrição SQL NOT IN e valores NULL

A partir do texto da pergunta, parece que o problema estava ocorrendo em uma SELECTconsulta SQL DML , em vez de uma DDL SQL CONSTRAINT.

No entanto, especialmente dada a redação do título, quero salientar que algumas declarações feitas aqui são declarações potencialmente enganosas, aquelas do tipo (parafraseando)

Quando o predicado é avaliado como DESCONHECIDO, você não recebe nenhuma linha.

Embora este seja o caso do SQL DML, ao considerar restrições, o efeito é diferente.

Considere esta tabela muito simples com duas restrições tiradas diretamente dos predicados da pergunta (e abordadas em uma excelente resposta 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;

De acordo com a resposta de @ Brannon, a primeira restrição (usando IN) é avaliada como VERDADEIRA e a segunda restrição (usando NOT IN) é avaliada como DESCONHECIDO. Contudo , a inserção foi bem-sucedida! Portanto, neste caso, não é estritamente correto dizer "você não recebe nenhuma linha" porque, de fato, temos uma linha inserida como resultado.

O efeito acima é de fato o correto em relação ao padrão SQL-92. Compare e contraste a seção a seguir da especificação SQL-92

7.6 cláusula where

O resultado de é uma tabela daquelas linhas de T para as quais o resultado da condição de pesquisa é verdadeiro.

4.10 Restrições de integridade

Uma restrição de verificação de tabela é atendida se, e somente se, a condição de pesquisa especificada não for falsa para qualquer linha de uma tabela.

Em outras palavras:

No SQL DML, as linhas são removidas do resultado quando WHEREavalia como DESCONHECIDO, porque não atende à condição "é verdadeira".

Em SQL DDL (ou seja, restrições), as linhas não são removidos a partir do resultado quando avaliam a desconhecida, dado que não satisfazem a condição "não é falsa".

Embora os efeitos no SQL DML e no SQL DDL possam parecer contraditórios, existe uma razão prática para dar aos resultados UNKNOWN o 'benefício da dúvida', permitindo que eles satisfaçam uma restrição (mais corretamente, permitindo que eles não deixem de satisfazer uma restrição). : sem esse comportamento, todas as restrições teriam que lidar explicitamente com nulos e isso seria muito insatisfatório do ponto de vista do design da linguagem (para não mencionar, um problema para os codificadores!)

ps Se você está achando tão desafiador seguir uma lógica como "desconhecido não falha em satisfazer uma restrição" como eu estou escrevendo, considere que você pode dispensar tudo isso simplesmente evitando colunas anuláveis ​​no DDL do SQL e qualquer coisa no SQL DML que produz nulos (por exemplo, junções externas)!

Em A, 3 é testado quanto à igualdade em relação a cada membro do conjunto, produzindo (FALSE, FALSE, TRUE, UNKNOWN). Como um dos elementos é VERDADEIRO, a condição é VERDADEIRA. (Também é possível que ocorra um curto-circuito aqui, portanto, ele pára assim que atinge o primeiro TRUE e nunca avalia 3 = NULL.)

Em B, acho que está avaliando a condição como NOT (3 in (1,2, null)). Teste 3 para igualdade em relação aos rendimentos definidos (FALSE, FALSE, UNKNOWN), que é agregado a UNKNOWN. NOT (DESCONHECIDO) gera DESCONHECIDO. Portanto, no geral, a verdade da condição é desconhecida, que no final é essencialmente tratada como FALSA.

Pode-se concluir a partir de respostas aqui que NOT IN (subquery)não tratam nulos corretamente e devem ser evitadas em favor de NOT EXISTS. No entanto, essa conclusão pode ser prematura. No cenário a seguir, creditado a Chris Date (Database Programming and Design, Vol. 2, n. 9, setembro de 1989), é NOT INque lida com nulos corretamente e retorna o resultado correto, em vez deNOT EXISTS .

Considere uma tabela sppara representar os fornecedores ( sno) que são conhecidos por fornecer peças ( pno) em quantidade ( qty). A tabela atualmente possui os seguintes valores:

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

Observe que a quantidade é anulável, ou seja, para poder registrar o fato de que um fornecedor é conhecido por fornecer peças, mesmo que não seja conhecido em qual quantidade.

A tarefa é encontrar os fornecedores que sabem o número da peça de fornecimento 'P1', mas não em quantidades de 1000.

Os seguintes usos usam NOT INpara identificar corretamente apenas o fornecedor 'S2':

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'
                       );

No entanto, a consulta abaixo usa a mesma estrutura geral, mas com, NOT EXISTSmas inclui incorretamente o fornecedor 'S1' no resultado (ou seja, para o qual a quantidade é nula):

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
                      );

Portanto, NOT EXISTSnão é a bala de prata que pode ter aparecido!

Obviamente, a fonte do problema é a presença de nulos; portanto, a solução 'real' é eliminar esses nulos.

Isso pode ser alcançado (entre outros projetos possíveis) usando duas tabelas:

• sp fornecedores conhecidos por fornecer peças
• spq fornecedores conhecidos por fornecer peças em quantidades conhecidas

observando que provavelmente deve haver uma restrição de chave estrangeira em que as spqreferênciassp .

O resultado pode ser obtido usando o operador relacional 'menos' (sendo a EXCEPTpalavra - chave no SQL padrão), por exemplo

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;

Nulo significa e ausência de dados, isto é, é desconhecido, não um valor de dados de nada. É muito fácil para as pessoas com experiência em programação confundirem isso, porque nas linguagens do tipo C, ao usar ponteiros nulos, de fato, nada é.

Portanto, no primeiro caso, 3 está realmente no conjunto de (1,2,3, nulo), então true é retornado

No segundo, você pode reduzi-lo para

selecione 'true' onde 3 não estão em (nulo)

Portanto, nada é retornado porque o analisador não sabe nada sobre o conjunto com o qual você está comparando - não é um conjunto vazio, mas um conjunto desconhecido. Usar (1, 2, nulo) não ajuda porque o conjunto (1,2) é obviamente falso, mas você está fazendo isso contra desconhecido, o que é desconhecido.

Se você deseja filtrar com NOT IN para uma subconsulta contendo NULLs, verifique se não é nulo

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

isto é para o menino:

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

isso funciona independentemente das configurações da ansi

SQL usa lógica de três valores para valores verdadeiros. A INconsulta produz o resultado esperado:

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

Mas adicionar a NOTnão inverte os resultados:

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

Isso ocorre porque a consulta acima é equivalente ao seguinte:

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

Aqui está como a cláusula where é avaliada:

| 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)                 |

Notar que:

1. A comparação envolvendo NULL rendimentosUNKNOWN
2. A ORexpressão em que nenhum dos operandos está TRUEe pelo menos um operando é UNKNOWNproduzida UNKNOWN( ref )
3. A NOTde UNKNOWNrendimentos UNKNOWN( ref )

Você pode estender o exemplo acima para mais de dois valores (por exemplo, NULL, 1 e 2), mas o resultado será o mesmo: se um dos valores for NULL, nenhuma linha corresponderá.

isso também pode ser útil para saber a diferença lógica entre associação, existe e em http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx