Operatore <>! = Non uguale su NULL

Qualcuno potrebbe spiegare il seguente comportamento in SQL?

SELECT * FROM MyTable WHERE MyColumn != NULL (0 Results)
SELECT * FROM MyTable WHERE MyColumn <> NULL (0 Results)
SELECT * FROM MyTable WHERE MyColumn IS NOT NULL (568 Results)

<>è SQL-92 standard; !=è il suo equivalente. Entrambi valutano i valori, il che NULLnon lo è - NULLè un segnaposto per dire che c'è l'assenza di un valore.

Ecco perché è possibile utilizzare IS NULL/ solo IS NOT NULLcome predicati per tali situazioni.

Questo comportamento non è specifico di SQL Server. Tutti i dialetti SQL conformi agli standard funzionano allo stesso modo.

Nota : per confrontare se il valore non è nullo , si utilizza IS NOT NULL, mentre per confrontare con valore non nullo , si utilizza <> 'YOUR_VALUE'. Non posso dire se il mio valore è uguale o meno uguale a NULL, ma posso dire se il mio valore è NULL o NOT NULL. Posso confrontare se il mio valore è diverso da NULL.

NULL non ha valore e quindi non può essere confrontato utilizzando gli operatori di valore scalare.

In altre parole, nessun valore può mai essere uguale a (o non uguale a) NULL perché NULL non ha valore.

Quindi, SQL ha speciali predicati IS NULL e IS NOT NULL per la gestione di NULL.

Si noti che questo comportamento è il comportamento predefinito (ANSI).

Se tu:

 SET ANSI_NULLS OFF

http://msdn.microsoft.com/en-us/library/ms188048.aspx

Otterrai risultati diversi.

SET ANSI_NULLS OFF apparentemente andrà via in futuro ...

In SQL, tutto ciò che valuti / calcoli con NULLrisultati in UNKNOWN

Ecco perché SELECT * FROM MyTable WHERE MyColumn != NULLo SELECT * FROM MyTable WHERE MyColumn <> NULLti dà 0 risultati.

Per fornire un controllo per i NULLvalori, viene fornita la funzione isNull.

Inoltre, è possibile utilizzare l' ISoperatore come utilizzato nella terza query.

Spero che questo ti aiuti.

L'unico test per NULL è IS NULL o IS NOT NULL. Test per l'uguaglianza è senza senso perché per definizione non si sa quale sia il valore.

Ecco un articolo di Wikipedia da leggere:

https://en.wikipedia.org/wiki/Null_(SQL)

Noi usiamo

SELECT * FROM MyTable WHERE ISNULL(MyColumn, ' ') = ' ';

per restituire tutte le righe in cui MyColumn è NULL o tutte le righe in cui MyColumn è una stringa vuota. Per molti un "utente finale", il problema NULL vs. stringa vuota è una distinzione senza necessità e punto di confusione.

Semplicemente non vedo la ragione funzionale e senza soluzione di continuità per cui i null non siano paragonabili ad altri valori o altri null, perché possiamo chiaramente confrontarli e dire che sono uguali o meno nel nostro contesto. È divertente. Solo a causa di alcune conclusioni logiche e coerenza, dobbiamo preoccuparci costantemente di ciò. Non è funzionale, rendilo più funzionale e lascia che filosofi e scienziati concludano se è coerente o meno e contiene "logica universale". :) Qualcuno potrebbe dire che è a causa di indici o qualcos'altro, dubito che quelle cose non possano essere fatte per supportare valori null come i valori. È come confrontare due bicchieri vuoti, uno è un bicchiere di vite e l'altro è un bicchiere di birra, non stiamo confrontando i tipi di oggetti ma i valori che contengono, gli stessi che potresti confrontare int e varchar, con null ' È ancora più semplice, è nulla e ciò che due cose hanno in comune, sono le stesse, chiaramente paragonabili a me e a tutti gli altri che scrivono sql, perché rompiamo costantemente quella logica confrontandole in modi strani a causa di alcuni standard ANSI. Perché non usare il potere del computer per farlo per noi e dubito che rallenterebbe le cose se tutto ciò che è correlato fosse costruito pensando a quello. "Non è nulla, non è niente", non è Apple, è un apfel, dai ... Funzionalmente è tuo amico e qui c'è anche la logica. Alla fine l'unica cosa che conta è la funzionalità e l'uso di null in quel modo porta più o meno funzionalità e facilità d'uso. È più utile? perché rompiamo costantemente questa logica confrontandola in modi strani a causa di alcuni standard ANSI. Perché non usare il potere del computer per farlo per noi e dubito che rallenterebbe le cose se tutto ciò che è correlato fosse costruito pensando a quello. "Non è nulla, non è niente", non è Apple, è un apfel, dai ... Funzionalmente è tuo amico e qui c'è anche la logica. Alla fine l'unica cosa che conta è la funzionalità e l'uso di null in quel modo porta più o meno funzionalità e facilità d'uso. È più utile? perché rompiamo costantemente questa logica confrontandola in modi strani a causa di alcuni standard ANSI. Perché non usare il potere del computer per farlo per noi e dubito che rallenterebbe le cose se tutto ciò che è correlato fosse costruito pensando a quello. "Non è nulla, non è niente", non è Apple, è un apfel, dai ... Funzionalmente è tuo amico e qui c'è anche la logica. Alla fine l'unica cosa che conta è la funzionalità e l'uso di null in quel modo porta più o meno funzionalità e facilità d'uso. È più utile? s non è apple è apfel, dai ... Funzionalmente è tuo amico e qui c'è anche la logica. Alla fine l'unica cosa che conta è la funzionalità e l'uso di null in quel modo porta più o meno funzionalità e facilità d'uso. È più utile? s non è apple è apfel, dai ... Funzionalmente è tuo amico e qui c'è anche la logica. Alla fine l'unica cosa che conta è la funzionalità e l'uso di null in quel modo porta più o meno funzionalità e facilità d'uso. È più utile?

Considera questo codice:

SELECT CASE WHEN NOT (1 = null or (1 is null and null is null)) THEN 1 ELSE 0 end

Quanti di voi sanno cosa restituirà questo codice? Con o senza NOT restituisce 0. Per me questo non è funzionale ed è confuso. In c # è tutto come dovrebbe essere, le operazioni di confronto restituiscono valore, logicamente anche questo produce valore, perché in caso contrario non c'è nulla da confrontare (tranne. Niente :)). Hanno appena "detto": qualsiasi cosa rispetto a null "restituisce" 0 e questo crea molte soluzioni alternative e mal di testa.

Questo è il codice che mi ha portato qui:

where a != b OR (a is null and b IS not null) OR (a IS not null and b IS null)

Devo solo confrontare se due campi (in cui) hanno valori diversi, potrei usare la funzione, ma ...

NULL Non può essere confrontato con alcun valore utilizzando gli operatori di confronto. NULL = NULL è falso. Null non è un valore. L'operatore IS è appositamente progettato per gestire i confronti NULL.

Vecchia domanda, ma quanto segue potrebbe offrire qualche dettaglio in più.

nullnon rappresenta alcun valore o un valore sconosciuto. Non specifica perché non vi è alcun valore, il che può portare ad alcune ambiguità.

Supponiamo di eseguire una query come questa:

SELECT *
FROM orders
WHERE delivered=ordered;

cioè, stai cercando righe in cui le date orderede deliveredsono uguali.

Cosa ci si aspetta quando una o entrambe le colonne sono nulle?

Poiché almeno una delle date è sconosciuta, non puoi aspettarti di dire che le 2 date sono uguali. Questo è anche il caso in cui entrambe le date sono sconosciute: come possono essere uguali se non sappiamo nemmeno cosa siano?

Per questo motivo, qualsiasi espressione trattata nullcome un valore deve fallire. In questo caso, non corrisponderà. Questo è anche il caso se provi quanto segue:

SELECT *
FROM orders
WHERE delivered<>ordered;

Ancora una volta, come possiamo dire che due valori non sono gli stessi se non sappiamo cosa siano.

SQL ha un test specifico per i valori mancanti:

IS NULL

In particolare non sta confrontando i valori, ma piuttosto cerca valori mancanti .

Infine, per quanto riguarda l' !=operatore, per quanto ne so, in realtà non rientra in nessuno degli standard, ma è ampiamente supportato. È stato aggiunto per far sentire i programmatori di alcune lingue più a loro agio. Francamente, se un programmatore ha difficoltà a ricordare quale lingua stanno usando, stanno iniziando male.

Vorrei suggerire questo codice che ho creato per scoprire se c'è un cambiamento in un valore, iessendo il nuovo valore ed dessendo il vecchio (anche se l'ordine non ha importanza). Del resto, una modifica da valore a null o viceversa è una modifica, ma da null a null non lo è (ovviamente, dal valore a un altro valore è una modifica ma dal valore allo stesso non lo è).

CREATE FUNCTION [dbo].[ufn_equal_with_nulls]
(
    @i sql_variant,
    @d sql_variant
)
RETURNS bit
AS
BEGIN
    DECLARE @in bit = 0, @dn bit = 0
    if @i is null set @in = 1
    if @d is null set @dn = 1

    if @in <> @dn
        return 0

    if @in = 1 and @dn = 1
        return 1

    if @in = 0 and @dn = 0 and @i = @d
        return 1

    return 0

END

Per usare questa funzione, puoi

declare @tmp table (a int, b int)
insert into @tmp values
(1,1),
(1,2),
(1,null),
(null,1),
(null,null)

---- in select ----
select *, [dbo].[ufn_equal_with_nulls](a,b) as [=] from @tmp

---- where equal ----
select *,'equal' as [Predicate] from @tmp where  [dbo].[ufn_equal_with_nulls](a,b) = 1

---- where not equal ----
select *,'not equal' as [Predicate] from @tmp where  [dbo].[ufn_equal_with_nulls](a,b) = 0

I risultati sono:

---- in select ----
a   b   =
1   1   1
1   2   0
1   NULL    0
NULL    1   0
NULL    NULL    1

---- where equal ----
1   1   equal
NULL    NULL    equal

---- where not equal ----
1   2   not equal
1   NULL    not equal
NULL    1   not equal

L'uso di sql_variant lo rende compatibile per vari tipi

NULL non è niente ... è sconosciuto. NULL non equivale a nulla. Ecco perché devi usare la frase magica IS NULL invece di = NULL nelle tue query SQL

Puoi fare riferimento a questo: http://weblogs.sqlteam.com/markc/archive/2009/06/08/60929.aspx