Auto-comparaison de valeur NULL dans une table

Je suis toujours perplexe concernant un comportement mystérieux de T-sql, comme le suivant

-- Create table t and insert values.  
use tempdb
CREATE TABLE dbo.t (a INT NULL);  
-- insert 3 values
INSERT INTO dbo.t values (NULL),(0),(1);  
GO  
set ansi_nulls off -- purposely turn off, so we can allow NULL comparison, such as null = null
go
-- expect 3 rows returned but only 2 returned (without null value row)
select * from dbo.t where a = a 

Il ne s'agit pas de récupérer toutes les lignes d'une table et pas non plus d'éviter d'utiliser ANSI_NULLS.

Je veux juste demander quelques éclaircissements pourquoi t-sql se comporte comme ça.

C'est un comportement surprenant mais à partir de la page MSDN SET ANSI_NULLS, nous pouvons au moins savoir que c'est le comportement attendu. Une raison de plus pour ne jamais utiliser ANSI_NULLS OFF:

SET ANSI_NULLSaffecte une comparaison uniquement si l'un des opérandes de la comparaison est une variable qui est NULLou un littéral NULL. Si les deux côtés de la comparaison sont des colonnes ou des expressions composées, le paramètre n'affecte pas la comparaison.

Bien que cela ne soit pas clair dans la documentation msdn, je pense que vous trouverez ce qui suit vrai

"SET ANSI_NULLS ON n'affecte une comparaison que si l'un des opérandes de la comparaison est soit une variable NULL soit un NULL littéral. Si les deux côtés de la comparaison sont des colonnes ou des expressions composées, le paramètre n'affecte pas la comparaison."

Voir ce /programming/2866714/how-does-ansi-nulls-work-in-tsql

Robert Sheldon dans l'article suivant de 2015 discute des comportements NULL et pourquoi ils échouent parfois (mais pas toujours)

https://www.simple-talk.com/sql/t-sql-programming/how-to-get-nulls-horribly-wrong-in-sql-server/

Il décrit 13 échecs NULL qu'un programmeur peut facilement déclencher.

Échec # 1: ne pas savoir ce que signifie NULL

Explication: NULL est une non-valeur, une valeur inexistante. Ce n'est pas zéro. Ce n'est pas une chaîne vide. Une valeur ne peut pas être égale à NULL. Il n'y a pas deux valeurs NULL égales .

C'est le problème de base, mais assurez-vous de lire les autres échecs.

Oui, les versions antérieures (pré-SQL Server 7 je crois) se comportaient différemment, plus comme ce que vous vouliez.

Cependant, si vous recherchez le problème sur Stack Overflow et Stack Exchange, vous trouverez de nombreux longs fils de discussion sur les problèmes.

Pour ajouter à la discussion, la définition de la norme SQL92 de NULL peut être interprétée de manière ambiguë. Voici un bon résumé de la gestion NULL et de l'interprétation de divers SGBD avec l'aimable autorisation de sqlite.org.

DIVULGATION : Je me souviens un peu d'avoir lu sur "l'ambiguïté" de SQL92 à partir d'une ancienne version (comme 6-8 ans) de la page sqlite.org liée ci-dessus, mais cette page a été mise à jour depuis.

La réponse de RLF ci-dessus a une bonne citation, mais si je ne suis pas d'accord avec Robert Sheldon, c'est uniquement parce que je considère que "quelque chose qui n'existe pas" (c'est-à-dire un NULL ) est philosophiquement et sémantiquement équivalent à "quelque chose d' autre qui n'existe pas". ". Si je veux comprendre la logique de Sheldon, alors on pourrait déclarer que la définition de NULL est également NULL. (S'il n'existe pas, comment pouvons-nous le définir? Creepy, hein?)

Je vois une variation du brassage Paradox de Russell ( et un mal de tête). : - \

Mais encore une fois, il s'agit d'une discussion sur la sémantique de la langue anglaise ( PAS SQL) et le débat sur la philosophie appartient ici . :-)