Porque é Que NULL = NULL avalia para false no servidor SQL

Quantos anos tem o Frank? Não sei. Quantos anos tem a Shirley? Não sei. O Frank e a Shirley têm a mesma idade?

A resposta correcta deve ser" eu não sei " (null), Não "Não", como Frank e Shirley podem ter a mesma idade, simplesmente não sabemos.

Aqui, espero esclarecer a minha posição.

Que NULL = NULL avalie FALSE está errado. O Hacker e o Mister responderam correctamente. Eis o porquê. Dewayne Christensen escreveu-me, num comentário a Scott Ivey.:

Já que estamos em dezembro, vamos usar um exemplo sazonal. Tenho dois presentes. Debaixo da árvore. Agora, diz - me se eu ... tenho duas da mesma coisa ou não.

Podem ser diferentes ou iguais. saber até que um abrir ambos os presentes. Quem sabe? Convidaste duas pessoas que não se conhecem e ambas te fizeram o mesmo dom - raro, mas não impossível.§. Então a pergunta: estes dois desconhecidos apresentam o mesmo (igual, =)? A resposta correta é: Desconhecido (i.e. NULL).

Este exemplo destinava-se a demonstrar que "..(false ou null, dependendo do seu sistema).."é uma resposta correcta-não é, apenas NULL está correcto. em 3VL (ou pode aceitar um sistema que dê respostas erradas?)

Uma resposta correta a esta pergunta {[29] } deve enfatizar estes dois pontos:

• a lógica de três valores (3VL) é contra-intuitiva (ver inúmeras outras questões sobre este assunto no Stackoverflow e em outro fórum para ter certeza);
• DBMSes baseados em SQL muitas vezes não respeitam nem mesmo 3VL, eles dão respostas erradas às vezes (como, o poster original afirmar, SQL Servidor fazer neste caso).

Por isso, reitero: o SQL não serve de nada forçar alguém a interpretar a propriedade reflexiva da igualdade, que afirma que:

for any x, x = x §§ (em Inglês claro: qualquer que seja o universo do discurso, uma "coisa" é sempre igual a si mesma).

.. em 3VL (TRUE, FALSE, NULL). A expectativa das pessoas se conformaria com 2VL (TRUE, FALSE, que mesmo em SQL é válido para todos os outros valores), i.e. x = x avaliar sempre para TRUE, para qualquer possível valor de x-sem exceções.

Note também que os NULLs são válidos " não-Valores " (como os seus apologistas fingem que são) que se pode atribuir como valores de atributos (??) como parte das variáveis de relação. Então eles são valores aceitáveis de cada tipo (domínio), não apenas do tipo de expressões lógicas.

Este era o meu ponto de vista.: NULL, como valor, é uma "besta estranha". Sem eufemismo, prefiro dizer: Disparate. Acho que esta formulação é muito mais clara e menos discutível - desculpe a minha fraca proficiência em inglês.

Este é apenas um dos problemas dos NULLs. É melhor evitá-los completamente, quando possível.

§ estamos preocupados com valores aqui, portanto, o fato de que os dois presentes são sempre dois diferentes objetos físicos não são uma objeção válida; se você não está convencido desculpe, é que não é este the place to explain the difference between value and "object" semantics (Relational Algebra has value semantics from the start - see Codd's information principle; I think that some SQL DBMS implementors don't even care about a common semantics).

§§ tanto quanto sei, este é um axioma aceito (de uma forma ou de outra, mas sempre interpretado em 2VL) desde a antiguidade e que exatamente porque é tão intuitivo. 3VLs (é uma família de lógicas na realidade) é muito mais desenvolvimento recente (mas não tenho certeza quando foi desenvolvido pela primeira vez).

Nota: se alguém vai introduzir Inferior, Unidade e Opção Tipos como tenta justificar o SQL Nulos, eu vou estar convencido de que somente depois de um exame detalhado que mostra como o SQL implementações com valores Nulos têm um tipo de som sistema e esclarecer, finalmente, que valores Nulos (estes "valores-não-muito-valores") realmente são.

---

Em que seguimento irei cita alguns autores. qualquer erro ou omissão é provavelmente minha e não dos autores originais.

Joe Celko no SQL NULLs

Vejo Joe Celko frequentemente citado neste fórum. Aparentemente ele é um autor muito respeitado aqui. Então, eu disse a mim mesmo: "o que ele escreveu sobre SQL NULLs? Como é que ele explica inúmeros problemas?". Um dos meus amigos tem uma versão ebook do SQL de Joe Celko para smarties: advanced SQL programming, 3rd edition . Deixa ver.

Primeiro, o índice. O que mais me impressiona é o número de vezes que NULL é mencionado e nos contextos mais variados:

3.4 aritmética e NULLs 109
3.5 converter os valores de e para null 110
3, 5, 1 NULLIF () função 110
6 NULLs: dados em falta no SQL 185
6. 4 Comparação Dos NULLs 190
6, 5 NULLs e lógica 190
6.5.1 NULLS in Subquery Predicates 191
6.5.2 soluções SQL normalizadas 193
6. 6 Matemática e NULLs 193
6, 7 funções e NULLs 193
6.8 NULLs e Línguas de Acolhimento 194
6.9 conselhos de concepção para os NULLs 195
6.9.1 evitar NULLs dos programas anfitriões 197
6.10 nota sobre valores nulos múltiplos 198
10.1 é o predicado nulo 241
10.1.1 Fontes de NULLs 242
...

E assim por diante. Soa-me a" caso especial desagradável". Vou entrar em alguns destes casos com excertos disto. livro, tentando limitar-me ao essencial, por razões de direitos autorais. Eu acho que estas citações caem dentro da doutrina de "uso justo" e eles podem até mesmo estimular a comprar o livro - então eu espero que ninguém vai reclamar (caso contrário, eu vou precisar apagar a maioria, se não todos). Além disso, abster-me-ei de comunicar trechos de código pela mesma razão. Sinto muito por isso. Compre o livro para ler sobre o raciocínio datailed.

Números de páginas entre parênteses no que se segue.

Não. Restrição nula (11)

A restrição mais importante da coluna é a não nula, que proíbe o uso de NULLs em uma coluna. Use esta restrição rotineiramente, e remova só quando tens uma boa razão. Irá ajudá-lo a evitar o complicações de valores nulos quando você faz consultas contra os dados.

Não é um valor; é um marcador que detém um lugar onde um valor pode ir.

Mais uma vez este "valor, mas não é bem um valor" absurdo. O resto parece-me bastante sensato.

(12)

Em resumo, NULLs causam muitas características irregulares no SQL, que discutiremos tarde. Sua melhor aposta é apenas para memorizar as situações e as regras para NULLs quando não podes evitá-los.

Apropos de SQL, NULLs e infinito:

(104) CAPÍTULO 3: DADOS NUMÉRICOS EM SQL

O SQL não aceitou o modelo IEEE para matemática por várias razões.

...

Se as regras de matemática do IEEE fossem permitidas SQL, então precisaríamos de regras de conversão de tipo para infinito e uma maneira de representar um valor numérico exato infinito após a conversão. Pessoa Já tenho problemas suficientes com NULLs, por isso não vamos por aí.

Implementações SQL indecisas sobre o que NULL realmente significa em contextos particulares:

3, 6.2 Funções Exponenciais (116)

O problema é que os logaritmos não são definidos quando (x algum SQL implementações devolvem uma mensagem de erro, algumas devolvem um NULL e DB2/ 400; versão 3 Lançamento 1 retornado * NEFINF (abreviação de "negative infinity") como resultado.

Joe Celko citando David McGovern e C. J.

6 NULLs: dados em falta no SQL (185)

No seu livro, Um guia para a Sybase e para o servidor SQL, David McGovern. e C. J. Date disse: "é a opinião deste escritor do que NULLs, em pelo menos como atualmente definido e implementado em SQL, são muito mais problemas do que eles valem e devem ser evitados; eles mostram muito estranho e comportamento inconsistente e pode ser uma fonte rica de erro e confusão. (Note-se que estas observações e críticas se aplicam a qualquer sistema isso suporta NULLs estilo SQL, não apenas para o servidor SQL especificamente.)"

NULLs como uma toxicodependência:

(186/187)

No resto deste livro, Vou pedir-te para não usares eles, que podem parecer contraditórios, mas não são. Pense em um NULL como uma droga; usá-la corretamente e funciona para você, mas abusá-la e pode arruinar todo. A sua melhor política é evitar NULLs quando pode e usar como deve ser.

A minha única objecção aqui é "usá-los correctamente" , que interage mal com comportamentos de implementação específicos.

6.5.1 NULLS em Subcontingente Predicados (191/192)

As pessoas esquecem-se que um subquery esconde muitas vezes uma comparação com um nulo. Considere estas duas tabelas:

...

O resultado estará vazio. Isto é contra-intuitivo, mas correcto.

(separador)

6.5.2 soluções SQL padrão (193)

O SQL-92 resolveu alguns dos problemas 3VL (lógica de três valores) adicionando um novo predicado da forma:

é [NÃO] VERDADEIRO | FALSO / DESCONHECIDO

Mas o desconhecido é uma fonte de problemas em si, de modo que a C. J. Date, em seu livro citado abaixo, recomends in chapter 4.5. Evitar Nulls em SQL:

• Não use a palavra-chave desconhecida em qualquer contexto.

Leia "à parte" em Desconhecido, também ligado abaixo.

6.8 NULLs e Línguas de Acolhimento (194)

No entanto, você deve saber como os NULLs são tratados quando têm para ser passado para um programa hospedeiro. Nenhuma língua de máquina normal para que uma incorporação é definida suporta NULLs, que é outro boa razão para evitar usá-los em seu esquema de banco de dados.

(separador)

6.9 conselhos de concepção para os NULLs (195) É uma boa ideia declarar todas as suas tabelas de base sem NULL restrições em todas as colunas sempre que possível. Os NULLs confundem as pessoas. que não sabem SQL, e NULLs são caro.

Objeção: NULLs confunde até as pessoas que conhecem bem o SQL., abaixar.

(195)

As nulas devem ser evitadas em Chaves estrangeiras. SQL permite este " benefício da dúvida" relação, mas pode causar uma perda de informação em consultas que envolvem ligações. Por exemplo, dado um código do número de peça em Inventário que é referenciado como uma chave estrangeira por uma tabela de encomendas, você terá problemas em obter uma listagem das partes que têm um NULL. Isto é ... uma relação obrigatória; você não pode encomendar uma parte que não existe.

(separador)

6.9.1 evitar NULLs dos programas anfitriões (197)

Você pode evitar colocar NULLs na base de dados a partir dos programas anfitriões com alguma disciplina de programação.

...

1. determinar o impacto dos dados em falta na programação e comunicação de informações: colunas numéricas com NULLs são um problema, porque as consultas mear as funções agregadas podem fornecer resultados enganosos.

(separador)

(227)

A soma () de um conjunto vazio é sempre nula. Um dos mais comuns erros de programação feitos ao usar este truque é escrever uma consulta que pode voltar mais do que uma fila. Se não pensasses nisso, talvez tenha escrito o último exemplo como:...

(separador)

10.1.1 Fontes de NULLs (242)

É importante lembrar onde podem ocorrer NULLs. são mais de apenas um possível valor numa coluna . Funções agregadas em conjuntos vazios, Juntas exteriores, expressões aritméticas com NULLs e operadores OLAP todos retornam NULLs. Estas construções aparecem muitas vezes como colunas em ponto.

(separador)

(301)

Outro problema com NULLs é encontrado quando você tenta converter Em predicados a existir predicado.

(separador)

As funções de todos os predicados e extremos (313)

É contra-intuitivo no início que estes dois predicados não são os mesmos em SQL:

...

Mas tens de te lembrar das regras para as funções extremas. retire todos os NULLs antes de retornar os valores maiores ou menores. O Todos os predicados não caem NULLs, então você pode colocá - los no resultado.

(separador)

(315)

No entanto, a definição da norma tem a seguinte redacção: negativo, para que NULLs obtenham o benefício da dúvida. ... Como podem ver, é uma boa ideia evitar NULLs em UNIQUE restricao.

Grupo de discussão por:

As nulas são tratadas como se todas fossem iguais uma à outra, e formem o seu próprio grupo. Cada grupo é então reduzido a um único remar em uma nova tabela de resultados que substitui a antiga.

Isto significa que para o grupo por cláusula NULL = NULL Não avalie para NULL, como em 3VL, mas avalie para TRUE.

O padrão SQL é confuso:

A ordem por e NULLs (329)

Se um valor-chave de ordenação que é nulo é considerado maior ou menor do que um valor-chave de ordenação. o valor não nulo é definido pela implementação, mas...

... Há produtos SQL que fazem isso de qualquer maneira.

Em Março de 1999, Chris Farrar levantou uma questão de uma das suas desenvolvedores que o levaram a examinar uma parte do padrão SQL que Pensei que tinha percebido. O Chris encontrou algumas diferenças entre o compreensão geral e redacção efectiva do caderno de especificações.

E assim por diante. Acho que o Celko já chega.

C. J. data em SQL NULLs

C. J. Date é mais radical sobre NULLs: evite NULLs em SQL, ponto. Em fact, chapter 4 of his SQL and Relational Theory: How to Write Accurate O código SQL é intitulado "no DUPLICATES, NO NULLS", com subcapítulos 4.4 o que há de errado com Nulls?" e " 4.5 evitar Nulls em SQL "(siga a ligação: graças ao Google Books, você pode ler algumas páginas on-line).

Fabian Pascal on SQL NULLs

A partir das suas questões práticas na gestão de bases de dados-uma referência para o Pensador (nenhum excerto on-line, desculpa.

10, 3 Implicações Práticas

10, 3, 1 SQL NULLs

... SQL sofre dos problemas inerentes ao 3VL, bem como de muitos peculiaridades, complicações, contraintuitividade e erros diretos [10, 11]; entre eles estão os seguintes:

• as funções agregadas (por exemplo, SUM (), AVG ()) ignoram NULLs (exceto para a contagem ()).
• uma expressão escalar numa tabela sem linhas avalia incorrectamente para nulo, em vez de 0.
• a expressão " NULL = NULL "é avaliada como nula, mas é realmente inválida em SQL; no entanto, a ordem por tratar NULLs como igual (o que quer que eles precedam ou seguem valores" regulares " é deixado para o fornecedor DBMS).
• a expressão " x não é nulo "não é igual a" não(x é nulo)", como é o caso em 2VL.

...

Todos os dialectos SQL implementados comercialmente seguem esta abordagem 3VL, e, portanto,, não só eles resolvem estes problemas, mas também têm espéficosname implementacao problemas que variam consoante os produtos .

Talvez dependa, mas eu pensei {[[0]} avalia para NULL como a maioria das operações com NULL como um operando.

Só porque não sabes o que são duas coisas, não significa que sejam iguais. Se quando você pensa em {[[0]} você pensa em "NULL" (string) então você provavelmente quer um teste diferente de igualdade como Postgresql ' s {[[1]} e IS NOT DISTINCT FROM

Http://www.postgresql.org/docs/8.4/static/functions-comparison.html

A expressão é distinta da expressão

A expressão não é distinta da expressão

Para entradas não-nulas, é diferente de is o mesmo que o operador. No entanto, se ambas as entradas forem nulas, devolve falso, E se apenas uma entrada for nula, devolve verdadeiro. Similarmente, não é distinto de é idêntico a = para entradas não nulas, mas retorna verdadeiro quando ambas as entradas são nulas, e falso quando apenas uma entrada é nula. Assim, estas construções efetivamente agem como se null fosse um valor de dados normal, ao invés de "desconhecido".

NULL não é igual a nada, nem mesmo a si mesmo. Minha solução pessoal para entender o comportamento de NULL é evitar usá-lo tanto quanto possível :).

O conceito de nulo é, no mínimo, questionável. Codd introduziu o modelo relacional e o conceito de nulo no contexto (e passou a propor mais de um tipo de nulo!) No entanto, a teoria relacional evoluiu desde os escritos originais de Codd: algumas de suas propostas foram retiradas (por exemplo, chave primária) e outras nunca foram capturadas (por exemplo, operadores teta). Na teoria relacional moderna (verdadeira teoria relacional, devo enfatizar) o nulo simplesmente não existe. Ver A Terceira Parte Manifesto. http://www.thethirdmanifesto.com/ A linguagem SQL sofre o problema da compatibilidade reversa. NULL encontrou seu caminho para SQL e estamos presos com ele. Indiscutivelmente, a implementação de NULL em SQL é defeituosa (a implementação do servidor SQL torna as coisas ainda mais complicadas devido à sua opção ANSI_NULLS).

Recomendo evitar a utilização de colunas Nuláveis nas tabelas de base.

---

Embora talvez não devesse ser tentado, só queria afirmar as minhas próprias correcções sobre como NULL funciona em SQL:

NULL = NULL avaliação a UNKNOWN.

UNKNOWN é um valor lógico.

NULL é um valor de dados.

Isto é fácil de provar, por exemplo.

SELECT NULL = NULL

Gera correctamente um erro no servidor SQL. Se o resultado fosse um valor de dados então nós esperaríamos ver NULL, como algumas respostas aqui (erradamente) sugerem que nós o faríamos.

O valor lógico UNKNOWN é tratado de forma diferente em DML SQL e DDL SQL. respectivamente.

Em SQL DML, UNKNOWN faz com que as linhas sejam removidas do conjunto de resultados.

Por exemplo:

CREATE TABLE MyTable
(
 key_col INTEGER NOT NULL UNIQUE, 
 data_col INTEGER
 CHECK (data_col = 55)
);

INSERT INTO MyTable (key_col, data_col)
   VALUES (1, NULL);

O INSERT tem sucesso nesta linha, mesmo que a condição CHECK se resolva a NULL = NULL. Isto é devido definido na norma SQL-92 ("ANSI"):

11, 6 Definição da restrição da tabela

3)

Se a restrição da tabela for uma verificação definição de restrição, então deixe SC ser a condição de busca imediatamente contido na verificacao definição e deixar T ser o nome da tabela incluído no quadro correspondente descritor da restrição; o quadro a restrição não é satisfeita se e apenas se

EXISTE ( SELECCIONE * DE T ONDE NÃO EXISTE (SC))

É verdade.

Leia isso de novo cuidadosamente, seguindo a lógica.

Em Inglês claro, a nossa nova linha acima recebe o "benefício da dúvida" sobre ser {[[6]} e ter permissão para passar.

Em SQL DML, a regra para a cláusula WHERE é muito mais fácil de seguir:

A condição de pesquisa é aplicada a cada linha de T. O resultado do a cláusula é um quadro dessas linhas de T pelo qual o resultado da pesquisa a condição é verdadeira.

Em Inglês claro, as linhas que avaliam a UNKNOWN são removidas do conjunto de resultados.

At technet existe uma boa explicação para como os valores nulos funcionam.

Nulo significa desconhecido.

Portanto, a expressão booleana

Valor = nulo

Não avalia como falso, avalia como nulo, mas se esse é o resultado final de uma cláusula onde, então nada é devolvido. Essa é uma maneira prática de fazê-lo, já que retornar nulo seria difícil de conceber.

É interessante e muito importante seguinte:

Se numa consulta temos

where (value=@param Or @param is null) And id=@anotherParam

E

• valor=1
• @param is null
• id = 123
• @anotherParam=123

Depois

"Valor=@param" avalia-se como nulo
"@param is null " avalia o verdadeiro
"id=@anotherParam" avalia o verdadeiro

Assim a expressão a avaliar torna-se

(nulo ou verdadeiro) e verdadeiro

Podemos ser tentados a pensar que aqui "null Or true" ser avaliado como nulo e, assim, toda a expressão se torna nula e a linha não será devolvida. Isto não é assim. Por quê?

Porque "nulo ou verdadeiro" avalia-se como verdadeiro, o que é muito lógico, uma vez que se um operando é verdadeiro com o ou-operador, então não importa o valor do outro operando, a operação retornará verdadeira. Assim, não importa que o outro operando seja desconhecido (null).

Então finalmente temos verdade=verdadeira e assim a linha será devolvida.

Nota: com a mesma lógica cristalina que" nulo ou verdadeiro "avalia como verdadeiro," nulo e verdadeiro " avalia como nulo.

Actualizar:
Ok, só para torná-lo completo eu quero adicionar o resto aqui também o que acontece bastante divertido em relação ao acima.

"nulo ou falso" é considerado nulo," nulo e falso " é considerado falso. :)

A lógica ainda é evidente como antes.

A MSDN tem um belo artigo descritivo sobre nulls e a lógica dos três estados que engendram.

Em resumo, O spec SQL92 define NULL como desconhecido, e NUL usado nos seguintes operadores causa resultados inesperados para os não iniciados:

= operator NULL   true   false 
NULL       NULL   NULL   NULL
true       NULL   true   false
false      NULL   false  true

and op     NULL   true   false 
NULL       NULL   NULL   false
true       NULL   true   false
false      false  false  false

or op      NULL   true   false 
NULL       NULL   true   NULL
true       true   true   true
false      NULL   true   false

Porque NULL significa "valor desconhecido" e dois valores desconhecidos não podem ser iguais.

Então, se para a nossa lógica NULL n°1 é igual a NULL n ° 2, então temos que dizer isso de alguma forma:

SELECT 1
WHERE ISNULL(nullParam1, -1) = ISNULL(nullParam2, -1)

Em que o valor conhecido -1 n°1 é igual a -1 n ° 2

A confusão surge do nível de indireção (abstração) que vem do uso de NULL.

Voltando à analogia "o que está debaixo da árvore de Natal", "desconhecido" descreve o estado de conhecimento sobre o que está na caixa A. Então, se não sabes o que está na caixa A, dizes que é "Desconhecido", mas isso não significa que "Desconhecido" está dentro da caixa. Algo além do desconhecido está na caixa, possivelmente algum tipo de objeto, ou possivelmente nada está caixa. Da mesma forma, se você não sabe o que está na caixa B, você pode rotular seu estado de conhecimento sobre o conteúdo como sendo "desconhecido". O seu estado de conhecimento sobre a caixa A é igual ao seu estado de conhecimento sobre a caixa B. (Seu estado de conhecimento em ambos os casos é "desconhecido"ou" eu não sei o que está na caixa".) Mas o conteúdo das Caixas pode ou não ser igual. Voltando ao SQL, idealmente só deve ser capaz de comparar valores quando sabemos o que são. Infelizmente, o rótulo que descreve uma falta de conhecimento é armazenado na própria célula, por isso estamos tentados a usá-lo como um valor. Mas não devemos usar isso como um valor, porque isso levaria a " o conteúdo da caixa A é igual ao conteúdo da caixa B quando não sabemos o que está na caixa A e/ou não sabemos o que está na caixa B. (Logicamente, a implicação "se eu não sei o que está na caixa A E se eu não sei o que está na caixa B, então o que está na caixa A = O que está na caixa B " é falso.) Viva, Cavalo Morto.

A Pergunta:
Um desconhecido é igual ao outro desconhecido?
(NULL = NULL)
Essa pergunta é algo que ninguém pode responder, por isso é por omissão verdadeiro ou falso, dependendo da sua configuração ansi_nulls.

No entanto, a questão:
Esta variável desconhecida é desconhecida?
Esta pergunta é completamente diferente e pode ser respondida com verdade.

Nullvariável = null é comparar os valores
nullVariable is null is comparing the state of the variable

Null é desconhecido em sql por isso não podemos esperar que duas incógnitas sejam iguais.

No entanto, você pode obter esse comportamento, definindo ANSI_ NULLs para desligar(Está ligado por omissão) Você será capaz de usar = operador para nulls

SET ANSI_NULLS off
if null=null
print 1
else 
print 2
set ansi_nulls on
if null=null
print 1
else 
print 2

Apenas uma adição a outras respostas maravilhosas:

AND: The result of true and unknown is unknown, false and unknown is false,
while unknown and unknown is unknown.

OR: The result of true or unknown is true, false or unknown is unknown, while unknown or unknown is unknown.

NOT: The result of not unknown is unknown

As respostas aqui parecem vir de uma perspectiva CS, por isso quero adicionar uma de uma perspectiva de desenvolvimento.

Para um programador NULL é muito útil. As respostas aqui dizem que nulo significa desconhecido, e talvez na teoria CS isso seja verdade, não me lembro, já passou algum tempo. No entanto, no desenvolvimento real, pelo menos na minha experiência, isso acontece cerca de 1% das vezes. Os outros 99% é usado para casos em que o valor não é Desconhecido, mas é conhecido por estar ausente.

Para exemplo:

• Client.LastPurchase, para um novo cliente. Não é Desconhecido, sabe-se que ele ainda não fez uma compra.

• Quando se utiliza um ORM com uma tabela por classe hierarquia mapeamento, alguns valores não são mapeados para certas classes.

• Ao mapear uma estrutura de árvore , uma raiz terá normalmente Parent = NULL

• E muitos mais...

Tenho a certeza que a maioria dos programadores escreveu WHERE value = NULL, não obtive resultados, e foi assim que aprenderam sobre a sintaxe IS NULL. Basta ver quantos votos esta pergunta e os que estão ligados têm.

As bases de Dados SQL são uma ferramenta, e devem ser concebidas da forma mais fácil para os seus utilizadores compreenderem.