Perché NULL = NULL restituisce false in SQL server

Nel server SQL se si ha nullParam=NULL in una clausola where, viene sempre valutata false. Questo è controintuitivo e mi ha causato molti errori. Capisco che le parole chiave IS NULL e IS NOT NULL siano il modo corretto per farlo. Ma perché SQL Server si comporta in questo modo?

Pensa al null come “sconosciuto” in quel caso (o “non esiste”). In entrambi i casi, non si può dire che siano uguali, perché non si conosce il valore di nessuno di essi. Quindi null = null non è vero (falso o nullo, a seconda del sistema), perché non si conoscono i valori per dire che sono uguali. Questo comportamento è definito nello standard ANSI SQL-92.

EDIT: dipende dall’impostazione ansi_nulls . se ANSI_NULLS è distriggersto, questo verrà valutato su true. Esegui il seguente codice per un esempio …

 set ansi_nulls off if null = null print 'true' else print 'false' set ansi_nulls ON if null = null print 'true' else print 'false' 

Quanti anni ha Frank? Non so (null).

Quanti anni ha Shirley? Non so (null).

Frank e Shirley sono della stessa età?

La risposta corretta dovrebbe essere “Non so” (null), non “no”, dato che Frank e Shirley potrebbero avere la stessa età, semplicemente non lo sappiamo.

Qui spero di chiarire la mia posizione.

Che NULL = NULL valuti a FALSE è sbagliato. Hacker e Mister hanno risposto correttamente a NULL . Ecco perché Dewayne Christensen mi ha scritto, in un commento a Scott Ivey :

Dato che è dicembre, usiamo un esempio stagionale. Ho due regali sotto l’albero. Ora, dimmi se ho avuto due della stessa cosa o no.

Possono essere diversi o possono essere uguali, non lo sai finché non si aprono entrambi i regali. Chissà? Hai invitato due persone che non si conoscono ed entrambi ti hanno fatto lo stesso dono – raro, ma non imansible § .

Quindi la domanda: questi due SCONOSCIUTI presentano lo stesso (uguale, =)? La risposta corretta è: UNKNOWN (cioè NULL ).

Questo esempio ha lo scopo di dimostrare che “.. ( false o null , a seconda del tuo sistema) ..” è una risposta corretta – non lo è, solo NULL è corretto in 3VL (o è ok per te accettare un sistema che dia risposte sbagliate?)

Una risposta corretta a questa domanda deve sottolineare questi due punti:

  • la logica a tre valori (3VL) è controintuitiva (vedere innumerevoli altre domande su questo argomento su Stackoverflow e in altri forum per essere sicuri);
  • I DBMS basati su SQL spesso non rispettano nemmeno il 3VL, a volte danno risposte sbagliate (come, asserisce il poster originale, SQL Server fa in questo caso).

Quindi ripeto: SQL non fa bene a forzare uno a interpretare la proprietà riflessiva dell’uguaglianza, che afferma che:

for any x, x = x §§ (in inglese semplice: qualunque sia l’universo del discorso, una “cosa” è sempre uguale a se stessa ).

.. in un 3VL ( TRUE , FALSE , NULL ). L’aspettativa delle persone sarebbe conforms a 2VL ( TRUE , FALSE , che anche in SQL è valido per tutti gli altri valori), cioè x = x valuta sempre a TRUE , per ogni ansible valore di x – nessuna eccezione.

Si noti inoltre che i NULL sono validi ” non-valori ” (come pretendono i loro apologeti) che si possono assegnare come valori di attributo (??) come parte delle variabili di relazione. Quindi sono valori accettabili di ogni tipo (dominio), non solo del tipo di espressioni logiche.

E questo era il mio punto : NULL , come valore, è una “strana bestia”. Senza eufemismo, preferisco dire: sciocchezze .

Penso che questa formulazione sia molto più chiara e meno discutibile – mi dispiace per la mia scarsa conoscenza dell’inglese.

Questo è solo uno dei problemi dei NULL. Meglio evitarli del tutto, quando ansible.

§ siamo preoccupati per i valori qui, quindi il fatto che i due regali siano sempre due oggetti fisici diversi non è una valida obiezione; se non sei convinto mi dispiace, non è questo il luogo per spiegare la differenza tra valore e semantica “object” (Algebra relazionale ha semantica del valore fin dall’inizio – vedi il principio di informazione di Codd, penso che alcuni implementatori di SQL DBMS don si preoccupano anche di una semantica comune).

§§ a mia conoscenza, questo è un assioma accettato (in una forma o in un’altra, ma sempre interpretato in un 2VL) sin dall’antichità e che proprio perché è così intuitivo. 3VLs (è una famiglia di logiche nella realtà) è uno sviluppo molto più recente (ma non sono sicuro di quando è stato sviluppato per la prima volta).

Nota a margine: se qualcuno introdurrà Bottom , Unit e Option Types come tentativi di giustificare NULL SQL, sarò convinto solo dopo un esame abbastanza dettagliato che mostrerà come le implementazioni SQL con NULL hanno un sistema di tipo sonoro e chiariranno, infine, cosa sono realmente i NULL (questi “valori-non-abbastanza-valori”).


In quanto segue citerò alcuni autori. Qualsiasi errore o omissione è probabilmente mio e non degli autori originali.

Joe Celko su SQL NULL

Vedo Joe Celko spesso citato su questo forum. Apparentemente è un autore molto rispettato qui. Così, mi sono detto: “cosa ha scritto su SQL NULL? Come spiega a NULL numerosi problemi?”. Uno dei miei amici ha una versione di Ebook di Joe Celko per smarties: programmazione SQL avanzata, terza edizione . Vediamo.

Innanzitutto, il sumrio. La cosa che mi colpisce di più è il numero di volte in cui NULL è menzionato e nei più svariati contesti:

3.4 Aritmetica e NULL 109
3.5 Conversione di valori da e verso NULL 110
3.5.1 Funzione NULLIF () 110
6 NULL: dati mancanti in SQL 185
6.4 Confronto di NULL 190
6.5 NULL e logica 190
6.5.1 NULLS nei predicati delle subquery 191
6.5.2 Soluzioni SQL standard 193
6.6 Math e NULL 193
6.7 Funzioni e valori NULL 193
6.8 NULL e lingue host 194
6.9 Consigli di progettazione per NULL 195
6.9.1 Evitare i valori NULL dai programmi host 197
6.10 Una nota su più valori NULL 198
10.1 IS NULL Predicate 241
10.1.1 Sorgenti di NULL 242

e così via. Suona “un brutto caso speciale” per me.

Entrerò in alcuni di questi casi con estratti da questo libro, cercando di limitarmi all’essenziale, per ragioni di copyright. Penso che queste citazioni rientrino nella doctrine del “fair use” e possono persino stimolare l’acquisto del libro – quindi spero che nessuno si lamenterà (altrimenti dovrò cancellarne la maggior parte, se non tutte). Inoltre, mi asterrò dal riferire frammenti di codice per lo stesso motivo. Mi dispiace per quello Compra il libro per leggere il ragionamento informatico.

Numeri di pagina tra parentesi in quello che segue.

NOT NULL Constraint (11)

Il vincolo di colonna più importante è il NOT NULL, che vieta l’uso di valori NULL in una colonna. Utilizzare questo vincolo di routine e rimuoverlo solo quando si ha una buona ragione. Ti aiuterà a evitare le complicazioni dei valori NULL quando fai domande sui dati.

Non è un valore ; è un indicatore che contiene un luogo in cui potrebbe andare un valore.

Di nuovo questa assurdità “valore ma non proprio un valore”. Il resto sembra abbastanza ragionevole per me.

(12)

In breve, i NULL causano molte caratteristiche irregolari in SQL, di cui parleremo in seguito. La tua migliore scommessa è solo per memorizzare le situazioni e le regole per i NULL quando non puoi evitarli.

A proposito di SQL, NULL e infinito:

(104) CAPITOLO 3: DATI NUMERICI IN SQL

SQL non ha accettato il modello IEEE per la matematica per diversi motivi.

Se le regole IEEE per la matematica fossero consentite in SQL, avremmo bisogno di regole di conversione dei tipi per infinito e un modo per rappresentare un valore numerico esatto infinito dopo la conversione. Le persone hanno abbastanza problemi con i NULL, quindi non andiamo lì.

Implementazioni SQL indecise su cosa NULL significhi realmente in contesti particolari:

3.6.2 Funzioni esponenziali (116)

Il problema è che i logaritmi non sono definiti quando (x <= 0). Alcune implementazioni SQL restituiscono un messaggio di errore, alcuni restituiscono un valore NULL e DB2 / 400; version 3 release 1 restituisce * NEGINF (abbreviazione di “infinito negativo”) come risultato.

Joe Celko citando David McGoveran e CJ Date:

6 NULL: Dati mancanti in SQL (185)

Nel loro libro A Guide to Sybase e SQL Server , David McGoveran e CJ Date hanno detto: “È opinione di chi scrive che i NULL, almeno come attualmente definiti e implementati in SQL, sono molto più difficili di quanto valgano e dovrebbero essere evitati; mostrano un comportamento molto strano e inconsistente e possono essere una fonte ricca di errori e confusione. (Si noti che questi commenti e critiche si applicano a tutti i sistemi che supportano NULL in stile SQL, non solo a SQL Server in particolare.) ”

Null come dipendenza da droga :

(186/187)

Nel resto di questo libro, ti esorto a non usarli , il che potrebbe sembrare contraddittorio, ma non lo è. Pensa a un NULL come a una droga; usarlo correttamente e funziona per te, ma abusarne e può rovinare tutto. La tua politica migliore è quella di evitare i NULL quando puoi e usarli correttamente quando necessario.

La mia unica obiezione qui è di “usarli correttamente”, che interagisce male con specifici comportamenti di implementazione.

6.5.1 NULLS nei predicati delle subquery (191/192)

La gente dimentica che spesso una sottoquery nasconde un confronto con un NULL. Considera queste due tabelle:

Il risultato sarà vuoto. Questo è controintuitivo , ma corretto.

(separatore)

6.5.2 Soluzioni SQL standard (193)

SQL-92 ha risolto alcuni dei problemi della 3VL (logica a tre valori) aggiungendo un nuovo predicato del modulo:

IS [NOT] TRUE | FALSO | SCONOSCIUTO

Ma SCONOSCIUTO è una fonte di problemi in sé, quindi CJ Date, nel suo libro citato di seguito, raccomanda nel capitolo 4.5. Evitare i null in SQL :

  • Non utilizzare la parola chiave UNKNOWN in nessun contesto.

Leggi “ASIDE” su UNKNOWN, anch’esso collegato sotto.

6.8 NULL e lingue host (194)

Tuttavia, dovresti sapere come vengono gestiti i NULL quando devono essere passati a un programma host. Nessuna lingua host standard per la quale è definita un’incorporazione supporta NULL, che è un’altra buona ragione per evitare di utilizzarli nello schema del database.

(separatore)

6.9 Design Advice for NULLs (195)

È consigliabile dichiarare tutte le tabelle di base con i vincoli NOT NULL su tutte le colonne, quando ansible. I NULL confondono le persone che non conoscono SQL e i NULL sono costosi.

Obiezione: i NULL confondono anche le persone che conoscono bene SQL, vedi sotto.

(195)

I valori NULL dovrebbero essere evitati in FOREIGN KEYs. SQL consente questa relazione “beneficio del dubbio”, ma può causare una perdita di informazioni nelle query che coinvolgono i join. Ad esempio, dato un codice del numero parte in Inventory a cui viene fatto riferimento come FOREIGN KEY da una tabella Orders, si avranno problemi a ottenere un elenco delle parti che hanno un valore NULL. Questa è una relazione obbligatoria; non puoi ordinare una parte che non esiste.

(separatore)

6.9.1 Evitare i valori NULL dai programmi host (197)

È ansible evitare di inserire NULL nel database dai programmi host con alcune regole di programmazione.

  1. Determinare l’impatto dei dati mancanti sulla programmazione e sul reporting: le colonne numeriche con NULL rappresentano un problema, poiché le query che utilizzano funzioni aggregate possono fornire risultati fuorvianti.

(separatore)

(227)

Il SUM () di un set vuoto è sempre NULL. Uno degli errori di programmazione più comuni creati quando si utilizza questo trucco è scrivere una query che potrebbe restituire più di una riga. Se non ci hai pensato, potresti aver scritto l’ultimo esempio come: …

(separatore)

10.1.1 Sorgenti di NULL (242)

È importante ricordare dove possono verificarsi NULL. Sono più di un semplice valore in una colonna . Le funzioni di aggregazione su insiemi vuoti, OUTER JOIN, espressioni aritmetiche con NULL e operatori OLAP restituiscono tutti valori NULL. Questi costrutti si presentano spesso come colonne in VIEW.

(separatore)

(301)

Un altro problema con NULL si trova quando si tenta di convertire i predicati IN in predicati EXISTS.

(separatore)

16.3 Le funzioni ALL Predicate ed Extrema (313)

In un primo momento è controintuitivo che questi due predicati non siano gli stessi in SQL:

Ma devi ricordare le regole per le funzioni extrema: eliminano tutti i NULL prima di restituire i valori maggiori o minimi. Il predicato ALL non rilascia NULL, quindi puoi ottenerli nei risultati.

(separatore)

(315)

Tuttavia, la definizione nello standard è formulata in senso negativo, in modo che i NULL ottengano il beneficio del dubbio. …

Come puoi vedere, è una buona idea evitare NULL nei vincoli UNIQUE.

Discutere di GROUP BY:

I valori NULL vengono considerati come se fossero tutti uguali tra loro e formano il proprio gruppo. Ogni gruppo viene quindi ridotto a una singola riga in una nuova tabella dei risultati che sostituisce quella precedente.

Ciò significa che per la clausola GROUP BY NULL = NULL non valuta NULL, come in 3VL, ma valuta TRUE.

Lo standard SQL è fonte di confusione:

ORDER BY e NULL (329)

Se un valore di chiave di ordinamento che è NULL è considerato maggiore o minore di un valore non NULL è definito dall’implementazione, ma …

… Ci sono prodotti SQL che lo fanno in entrambi i modi.

Nel marzo 1999, Chris Farrar sollevò una domanda da uno dei suoi sviluppatori che gli fece esaminare una parte dello standard SQL che pensavo di aver capito . Chris ha riscontrato alcune differenze tra la comprensione generale e la formulazione effettiva della specifica .

E così via. Penso che sia abbastanza per Celko.

Data CJ su NULL SQL

CJ Date è più radicale sui NULL: evitare i NULL in SQL, punto. In effetti, il capitolo 4 della sua teoria SQL e relazionale: Come scrivere un codice SQL accurato è intitolato “NO DUPLICATES, NO NULLS”, con sottocapitoli “4.4 Cosa c’è di sbagliato con i null?” e “4.5 Evitare i null in SQL” (segui il link: grazie a Google Books puoi leggere alcune pagine online).

Fabian Pascal su SQL NULL

Dai suoi problemi pratici nella gestione dei database – Un riferimento per il praticante di pensiero (nessun estratto on-line, scusate):

10.3 Implicazioni pratiche

10.3.1 NULL SQL

… SQL soffre dei problemi inerenti alla 3VL e di molte stranezze, complicazioni, controintuitività ed errori definitivi [10, 11]; tra questi sono i seguenti:

  • Le funzioni di aggregazione (ad esempio, SUM (), AVG ()) ignorano i valori NULL (ad eccezione di COUNT ()).
  • Un’espressione scalare su una tabella senza righe viene valutata in modo errato su NULL, anziché su 0.
  • L’espressione “NULL = NULL” restituisce NULL, ma in realtà non è valida in SQL; tuttavia ORDER BY considera NULL uguali (qualunque cosa preceda o segua valori “normali” viene lasciato al fornitore DBMS).
  • L’espressione “x IS NOT NULL” non è uguale a “NOT (x IS NULL)”, come nel caso di 2VL.

Tutti i dialetti SQL implementati commercialmente seguono questo approccio 3VL e, quindi, non solo espongono questi problemi, ma hanno anche problemi di implementazione specifici, che variano tra i vari prodotti .

Forse dipende, ma ho pensato che NULL=NULL valuti a NULL come la maggior parte delle operazioni con NULL come operando.

Solo perché non sai cosa sono due cose, non significa che siano uguali. Se quando pensi a NULL pensi a “NULL” (stringa), allora probabilmente vuoi un test diverso di uguaglianza come Postgresql. IS DISTINCT FROM E IS NOT DISTINCT FROM

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

espressione È DISTINTA DA espressione

espressione NON È DISTINTA DA espressione

Per gli input non null, IS DISTINCT FROM è uguale all’operatore <>. Tuttavia, se entrambi gli input sono nulli, restituisce false e, se un solo input è nullo, restituisce true. Analogamente, IS NOT DISTINCT FROM è identico a = per gli input non nulli, ma restituisce true quando entrambi gli input sono nulli e false quando solo un input è nullo. Pertanto, questi costrutti si comportano in modo efficace come se null fossero un valore di dati normale, piuttosto che “sconosciuto”.

NULL non è uguale a niente, nemmeno a se stesso. La mia soluzione personale per comprendere il comportamento di NULL è di evitare di usarlo il più ansible :).

Il concetto di NULL è discutibile, per non dire altro. Codd ha introdotto il modello relazionale e il concetto di NULL nel contesto (e ha continuato a proporre più di un tipo di NULL!) Tuttavia, la teoria relazionale si è evoluta dagli scritti originali di Codd: alcune delle sue proposte sono state abbandonate (es. Chiave primaria) e altri mai presi in considerazione (ad esempio gli operatori theta). Nella teoria relazionale moderna (teoria veramente relazionale, dovrei sottolineare) NULL semplicemente non esiste. Vedi il terzo manifesto. http://www.thethirdmanifesto.com/

Il linguaggio SQL soffre il problema della retrocompatibilità. NULL ha trovato la sua strada in SQL e siamo bloccati con esso. Probabilmente, l’implementazione di NULL in SQL è imperfetta (l’implementazione di SQL Server rende le cose ancora più complicate grazie alla sua opzione ANSI_NULLS ).

Raccomando di evitare l’uso di colonne NULLable nelle tabelle di base.


Anche se forse non dovrei essere tentato, volevo solo affermare una mia correzione su come funziona NULL in SQL:

NULL = NULL restituisce UNKNOWN .

UNKNOWN è un valore logico.

NULL è un valore di dati.

Questo è facile da dimostrare ad es

SELECT NULL = NULL

genera correttamente un errore in SQL Server. Se il risultato fosse un valore di dati, ci aspetteremmo di vedere NULL , poiché alcune risposte qui (erroneamente) suggeriscono che lo faremmo.

Il valore logico UNKNOWN viene trattato in modo diverso rispettivamente in SQL DML e SQL DDL.

In SQL DML, UNKNOWN fa sì che le righe vengano rimosse dal set di risultati.

Per esempio:

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

L’ INSERT successo per questa riga, anche se la condizione CHECK si risolve in NULL = NULL . Questo è dovuto definito nello standard SQL-92 (“ANSI”):

11.6 definizione del vincolo di tabella

3)

Se il vincolo della tabella è una definizione del vincolo di controllo, allora sia SC la condizione di ricerca immediatamente contenuta nella definizione del vincolo di controllo e sia T il nome della tabella incluso nel descrittore del vincolo della tabella corrispondente; il vincolo della tabella non è soddisfatto se e solo se

ESISTE (SELEZIONARE * DA T WHERE NOT (SC))

è vero.

Leggi di nuovo attentamente, seguendo la logica.

In parole povere, la nostra nuova riga sopra è data il “beneficio del dubbio” sull’essere UNKNOWN e permesso di passare.

In SQL DML, la regola per la clausola WHERE è molto più semplice da seguire:

La condizione di ricerca viene applicata a ciascuna riga di T. Il risultato della clausola where è una tabella di quelle righe di T per cui il risultato della condizione di ricerca è true.

In inglese semplice, le righe che valutano in UNKNOWN vengono rimosse dal gruppo di risultati.

A technet c’è una buona spiegazione su come funzionano i valori nulli.

Nullo significa sconosciuto.

Quindi l’espressione booleana

value = null

non valuta false, valuta null, ma se questo è il risultato finale di una clausola where, non viene restituito nulla. Questo è un modo pratico per farlo, poiché restituire null sarebbe difficile da concepire.

È interessante e molto importante capire quanto segue:

Se in una query che abbiamo

 where ([email protected] Or @param is null) And [email protected] 

e

  • Valore = 1
  • @param è nullo
  • id = 123
  • @ AnotherParam = 123

poi

“value = @ param” restituisce null
“@param is null” è true
“id = @ anotherParam” restituisce true

Quindi l’espressione da valutare diventa

(nulla o vero) E vero

Potremmo essere tentati di pensare che qui “null or true” sarà valutato come null e quindi l’intera espressione diventa null e la riga non verrà restituita.

Non è così. Perché?

Poiché “null or true” viene valutato su true, il che è molto logico, poiché se un operando è true con l’operatore Or, indipendentemente dal valore dell’altro operando, l’operazione restituirà true. Quindi non importa che l’altro operando sia sconosciuto (null).

Quindi finalmente abbiamo true = true e quindi la riga verrà restituita.

Nota: con la stessa logica cristallina che “null or true” restituisce true, “null And true” restituisce null.

Aggiornare:
Ok, solo per completarlo voglio aggiungere il resto anche qui, che risulta piuttosto divertente in relazione a quanto sopra.

“null or false” restituisce null, “null And false” viene valutato come falso. 🙂

La logica è ovviamente ancora così evidente come prima.

MSDN ha un bell’articolo descrittivo sui null e la logica dei tre stati che generano.

In breve, la specifica SQL92 definisce NULL come sconosciuto e NUL utilizzato nei seguenti operatori causa risultati non previsti per i non iniziati:

 = 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 

Poiché NULL significa “valore sconosciuto” e due valori sconosciuti non possono essere uguali.

Quindi, se per la nostra logica NULL N ° 1 è uguale a NULL N ° 2, allora dobbiamo dire che in qualche modo:

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

dove il valore noto -1 N ° 1 è uguale a -1 N ° 2

La confusione deriva dal livello di indirezione (astrazione) che deriva dall’uso di NULL .

Tornando all’analogia “cosa c’è sotto l’albero di Natale”, “Sconosciuto” descrive lo stato delle conoscenze su ciò che è nella casella A.

Quindi, se non sai cosa c’è nel riquadro A, dici che è “Sconosciuto”, ma ciò non significa che “Sconosciuto” sia all’interno della scatola . Qualcosa di diverso da quello sconosciuto è nella scatola, forse un qualche tipo di object, o forse nulla è nella scatola.

Allo stesso modo, se non sai cosa c’è nel Box B, puoi etichettare il tuo stato di conoscenza dei contenuti come “Sconosciuto”.

Quindi ecco il kicker: il tuo stato di conoscenza del Box A è uguale al tuo stato di conoscenza del Box B. (Il tuo stato di conoscenza in entrambi i casi è “Sconosciuto” o “Non so cosa c’è nella scatola”.) Ma il contenuto delle scatole può essere o meno uguale.

Tornando a SQL, idealmente dovresti essere in grado di confrontare i valori solo quando sai cosa sono. Sfortunatamente, l’etichetta che descrive una mancanza di conoscenza è memorizzata nella cella stessa , quindi siamo tentati di usarla come valore. Ma non dovremmo usarlo come valore, perché porterebbe a “il contenuto della Casella A è uguale al contenuto della Casella B quando non sappiamo cosa c’è nella Casella A e / o non sappiamo cosa c’è nella Casella B. (Logicamente, l’implicazione “se non so cosa c’è nel riquadro A e se non so cosa c’è nel riquadro B, allora quello che c’è nel riquadro A = cosa c’è nel riquadro B” è falso).

Yay, Dead Horse.

La domanda:
A uno sconosciuto corrisponde un altro sconosciuto?
(NULL = NULL)
Quella domanda è qualcosa a cui nessuno può rispondere in modo che sia impostata su true o false a seconda dell’impostazione ansi_nulls.

Comunque la domanda:
Questa variabile sconosciuta è sconosciuta?
Questa domanda è molto diversa e si può rispondere con verità.

nullVariable = null sta confrontando i valori
nullVariable è null sta confrontando lo stato della variabile

null è sconosciuto in sql quindi non possiamo aspettarci che due incognite siano uguali.

Tuttavia è ansible ottenere questo comportamento impostando ANSI_NULLS su Off (il suo On per impostazione predefinita) sarà ansible utilizzare l’operatore = per null

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

Solo un’aggiunta ad altre meravigliose risposte:

 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 

Le risposte qui sembrano provenire da una prospettiva CS, quindi voglio aggiungerne una dal punto di vista dello sviluppatore.

Per uno sviluppatore, NULL è molto utile. Le risposte qui dicono che NULL significa sconosciuto, e forse nella teoria CS è vero, non ricordo, è passato un po ‘di tempo. Nello sviluppo attuale però, almeno nella mia esperienza, ciò accade circa l’1% delle volte. L’altro 99% è utilizzato per i casi in cui il valore non è SCONOSCIUTO ma è NOTATO PER ESSERE ASSENTE.

Per esempio:

  • Client.LastPurchase , for a new client. It is not unknown, it is known that he hasn’t made a purchase yet.

  • When using an ORM with a Table per Class Hierarchy mapping, some values are just not mapped for certain classs.

  • When mapping a tree structure a root will usually have Parent = NULL

  • And many more…

I’m sure most developers at some point wrote WHERE value = NULL , didn’t get any results, and that’s how they learned about IS NULL syntax. Just look how many votes this question and the linked ones have.

SQL Databases are a tool, and they should be designed the way which is easiest for their users to understand.