Dlaczego NULL = NULL jest obliczany na false w SQL server

Ile ma lat Frank? Nie wiem (null).

Ile lat ma Shirley? Nie wiem (null).

Poprawną odpowiedzią powinno być "nie wiem" (null), A Nie "Nie", ponieważ Frank i Shirley mogą BYĆ w tym samym wieku, po prostu nie wiemy.

Tutaj mam nadzieję wyjaśnić moje stanowisko.

To NULL = NULL ocenianie na {[1] } jest złe. Hacker i Mister poprawnie odpowiedzieli NULL. Oto dlaczego. Dewayne Christensen napisał do mnie w komentarzu do Scott Ivey :

Ponieważ jest Grudzień, użyjmy przykład sezonowy. Mam dwa prezenty. pod drzewem. Teraz powiedz mi, czy ja mam dwie takie same rzeczy lub nie.

Mogą być różne lub mogą być równe, nie wiesz dopóki nie otworzymy obu prezentów. Kto wie? Zaprosiłeś dwie osoby, które się nie znają i obie zrobiły ci ten sam dar-rzadki, ale nie niemożliwy §.

Więc pytanie: czy te dwa nieznane prezenty są takie same (równe,=)? Prawidłowa odpowiedź brzmi: nieznany (tj. NULL).

Ten przykład miał zademonstrować , że"..(false lub null, w zależności od systemu).."jest poprawną odpowiedzią - nie jest, tylko NULL jest poprawny w 3VL (lub Czy akceptujesz system, który daje złe odpowiedzi?)

Poprawna odpowiedź na to pytanie musi podkreślić te dwa punkty:

• logika trójwartościowa (3VL) jest kontrintuicyjna (zobacz niezliczone inne pytania na ten temat na Stackoverflow i na innym forum, aby się upewnić);
• bazujące na SQL Dbmsy często nie respektują nawet 3VL, czasami dają błędne odpowiedzi (tak jak w tym przypadku robi to oryginalny poster, SQL Server).

Więc Ja powtórzę: SQL nie ma żadnego dobrego zmuszania do interpretacji refleksyjnej własności równości, która stwierdza, że:

for any x, x = x §§ (w języku angielskim: niezależnie od wszechświata dyskursu, "rzecz" jest zawsze równa sobie).

.. w 3VL (TRUE, FALSE, NULL). Oczekiwanie ludzi będzie zgodne z 2VL (TRUE, FALSE, które nawet w SQL jest ważne dla wszystkich innych wartości), tzn. x = x zawsze oceniaj do TRUE, na wszelkie możliwe wartość x-brak WYJĄTKÓW.

Zauważ również, że null są poprawne " Nie-wartości " (jak ich apologeci udają, że są), które można przypisać jako wartości atrybutów(??) jako część zmiennych relacji. Są więc akceptowalnymi wartościami każdego typu (domeny), a nie tylko typu wyrażeń logicznych.

I o to mi chodziło: NULL, jako wartość, jest "dziwna bestia". Bez eufemizmu wolę powiedzieć: nonsens.

Myślę, że to sformułowanie jest o wiele bardziej jasne i mniej dyskusyjne-przepraszam za moją słabą znajomość angielskiego.

To jest tylko jeden z problemów null. Lepiej unikać ich całkowicie, jeśli to możliwe.

§ martwimy się o wartości tutaj, więc fakt, że dwa prezenty są zawsze dwa różne obiekty fizyczne nie są słusznym sprzeciwem; jeśli nie jesteś przekonany, przepraszam, to nie jest to miejsce na wyjaśnienie różnicy między wartością i semantyka" obiektowa " (Algebra relacyjna ma semantykę wartościową od początku-patrz zasada informacyjna Codda; myślę, że niektórzy implementatorzy SQL DBMS nawet nie dbają o powszechną semantykę).

§§ według mojej wiedzy jest to aksjomat akceptowany (w takiej czy innej formie, ale zawsze interpretowany w 2VL) od starożytności i to dokładnie , ponieważ jest tak intuicyjny. 3VLs (to rodzina logiki w rzeczywistości) to znacznie nowszy rozwój (ale nie jestem pewien, kiedy był pierwszy opracowany).

Uwaga: jeśli ktoś wprowadzi dół, typy Unit i Option jako próby uzasadnienia null SQL, przekonam się dopiero po dość szczegółowym badaniu, które pokaże, jak implementacje SQL z Null mają system typów dźwiękowych i wyjaśni wreszcie, czym tak naprawdę są null (te "wartości-nie-całkiem-wartości").

W dalszej części przytoczę kilku autorów. jakikolwiek błąd lub pominięcie na prawdopodobnie moje, a nie oryginalnych autorów.

Joe Celko on SQL NULLs

Najpierw spis treści. Rzecz to, co uderza mnie najbardziej, to liczba razy, że NULL jest wymienione i w najróżniejszych kontekstach: {]}

3.4 arytmetyka i null 109
3.5 Konwersja wartości do i z NULL 110
3.5.1 funkcja NULLIF() 110
6 NULLs: brak danych w SQL 185
6.4 Porównanie NULLs 190
6.5 NULLs i logika 190
6.5.1 NULLS w Predykatach Subquery 191
6.5.2 Standardowe rozwiązania SQL 193
6.6 Matematyka i nulle 193
6.7 Funkcje i nulle 193
6.8 NULLs i języki hostów 194
6.9 porady projektowe dla NULLs 195
6.9.1 unikanie null z programów hosta 197
6.10 uwaga na wiele wartości NULL 198
10.1 jest predykatem NULL 241
10.1.1 Źródła NULLs 242
...

I tak dalej. Brzmi jak "paskudny przypadek specjalny".

Numery stron między nawiasami w tym, co następuje.

Nie null Constraint (11)

Najbardziej ważnym ograniczeniem kolumny jest NOT NULL, które zabrania użycie Null w kolumnie. Używaj tego ograniczenia rutynowo i usuń tylko wtedy, gdy masz dobry powód. Pomoże Ci to uniknąć komplikacje wartości NULL podczas wykonywania zapytań o dane.

Nie jest to wartość; jest to znacznik, który utrzymuje miejsce, w którym wartość może pójść.

Znowu ten nonsens "wartość, ale nie całkiem wartość". Reszta wydaje się całkiem rozsądna dla ja.

(12)

Krótko mówiąc, null powoduje wiele nieregularnych funkcji w SQL, które omówimy później. Najlepiej zapamiętać sytuacje i zasady null kiedy nie można ich uniknąć.

Apropos SQL, NULLs i infinite:

(104) ROZDZIAŁ 3: DANE LICZBOWE W SQL

SQL nie zaakceptował modelu IEEE dla matematyki z kilku powodów.

...

Jeśli IEEE zasady matematyki były dozwolone w SQL, wtedy potrzebowalibyśmy reguł konwersji typu dla infinite i sposobu na reprezentują nieskończoną dokładną wartość liczbową po konwersji. Ludzie mam dość problemów z Nullami, więc nie idźmy tam.

Implementacje SQL niezdecydowane co tak naprawdę oznacza NULL w poszczególnych kontekstach:

3.6.2 Funkcje Wykładnicze (116)

Problem polega na tym, że logarytmy są niezdefiniowane, gdy (x Some SQL implementacje zwracają komunikat o błędzie, niektóre zwracają NULL i DB2/ 400; version 3 release 1 returned * NEGINF (skrót od " negative infinity") w rezultacie.

Joe Celko cytuje Davida Mcgoverana i C. J. Date:

6 NULLs: brak danych w SQL (185)

[[16]}w swojej książce Przewodnik po Sybase i SQL Server , David McGoveran A C. J. Date powiedział: "to opinia tego pisarza niż nulla, przynajmniej jako obecnie zdefiniowane i zaimplementowane w SQL, są o wiele bardziej kłopotliwe niż są warte i należy ich unikać; wykazują bardzo dziwne i niespójne zachowanie i może być bogatym źródłem błędów i zamieszania. (Należy pamiętać, że te komentarze i krytyczne uwagi dotyczą każdego systemu obsługuje Null w stylu SQL, a nie tylko SQL Server.)"

NULLs jako narkomania :

(186/187)

W dalszej części tej książki, będę cię namawiał nie używać one [28], które mogą wydawać się sprzeczne, ale tak nie jest. Pomyśl o NULL jako narkotyk; używaj go właściwie i działa na ciebie, ale nadużywaj go i może zrujnować wszystko. Twoją najlepszą polityką jest unikanie null, kiedy możesz I używasz są odpowiednie, kiedy trzeba.

Moim unikalnym sprzeciwem jest "używanie ich właściwie" , co źle współgra z specyficzne zachowania implementacyjne.

6.5.1 NULLS w Predykatach Subquery (191/192)

Ludzie zapominają, że zapytanie podrzędne często ukrywa porównanie z NULL. Rozważmy te dwie tabele:

...

Wynik będzie pusty. To jest przeciwstawne, ale poprawne.

(separator)

6.5.2. Standardowe rozwiązania SQL (193)

SQL - 92 rozwiązał niektóre problemy 3VL (logika trójwartościowa) dodając nowy predykat postaci:

IS [NOT] TRUE / FALSE | UNKNOWN

Ale nieznane jest źródłem problemów samo w sobie, więc C. J. Date, w swojej książce przytoczonej poniżej, reccomends w rozdziale 4.5. Unikanie Null w SQL :

• nie używaj słowa kluczowego nieznany w żadnym kontekście.

Przeczytaj "na bok" na Nieznany, również podlinkowany poniżej.

6.8 NULLs i języki hosta (194)

Powinieneś jednak wiedzieć, jak nulle są obsługiwane, gdy mają być przekazany do programu hosta. Brak standardowego języka hosta dla którego osadzenie jest definiowane jako NULL, co jest kolejnym dobry powód, aby unikać używania ich w schemacie bazy danych.

(separator)

6.9. porady projektowe dla null (195)

Dobrym pomysłem jest zadeklarowanie wszystkich tabel bazowych za pomocą NOT NULL ograniczenia dotyczące wszystkich kolumn w miarę możliwości. NULLs mylą ludzi którzy nie znają SQL, a NULL są drogie.

Sprzeciw: NULLs myli nawet osoby, które dobrze znają SQL, patrz poniżej.

(195)

Null należy unikać w klawiszach obcych. SQL pozwala na to " korzyści związku wątpliwości" , ale może to spowodować utratę informacji w zapytania, które dotyczą łączenia. Na przykład podany kod numeru części w Inwentaryzacja, która jest określana jako klucz obcy przez tabelę zamówień, ty będzie miał problemy z uzyskaniem Listy części, które mają NULL. To jest obowiązkowy związek; ty nie można zamówić części, która nie istnieje.

(separator)

6.9.1 unikanie null z programów hostujących (197)

Możesz uniknąć umieszczania Null w bazie danych z programów hosta z pewną dyscypliną programowania.

...

1. określenie wpływu brakujących danych na programowanie i raportowanie: kolumny liczbowe z Null są problemem, ponieważ zapytania korzystanie z funkcji agregujących może wprowadzać w błąd wyniki.

(separator)

(227)

Sum() pustego zbioru jest zawsze NULL. Jednym z najczęstszych błędy programistyczne popełniane przy użyciu tej sztuczki polega na napisaniu zapytania, które może zwrócić więcej niż jeden rząd. Jeśli o tym nie pomyślałeś, możesz ostatni przykład napisał:...

(separator)

10.1.1 Źródła null (242)

Ważne jest, aby pamiętać, gdzie NULLs może wystąpić. są więcej niż tylko możliwa wartość w kolumnie . Agregacja funkcji na pustych zbiorach, Złączenia zewnętrzne, wyrażenia arytmetyczne z Null oraz operatory OLAP / align = "left" / Konstrukcje te często pojawiają się jako kolumny w Widoki.

(separator)

(301)

Inny problem z Null znajduje się podczas próby konwersji W predykatach do predykatów EXISTS.

(separator)

16.3 The Wszystkie funkcje predykatu i ekstremy (313)

Na początku jest sprzeczne z intuicją, że te dwa predykaty nie są takie same w SQL:]}

...

Ale trzeba pamiętać o regułach funkcji ekstrema-one odrzuć wszystkie wartości null przed zwróceniem większych lub najmniejszych wartości. Na Wszystkie predykaty nie upuszczają null, więc można je uzyskać w wynikach.

(separator)

(315)

[[16]}jednak definicja w standard jest sformułowany w negatywne, tak aby null czerpał korzyści z wątpliwości. ...

Jak widać, dobrym pomysłem jest unikanie Null w unikalnych ograniczenia.

Dyskusja grupy przez:

Null są traktowane tak, jakby wszystkie były sobie równe , oraz tworzą własną grupę. Każda grupa jest następnie zredukowana do jednej wiersz w nowej tabeli wyników, która zastępuje starą.

Oznacza to, że dla klauzuli GROUP BY NULL = NULL nie evaluate to NULL, jak w 3VL, ale to evaluate to TRUE.

Standard SQL jest mylący:

The ORDER BY and NULLs (329)

Czy wartość klucza sortowania, która jest NULL, jest uważana za większą lub mniejszą niż wartość non-NULL jest zdefiniowana w implementacji, ale...

... Istnieją produkty SQL, które robią to tak czy inaczej.

W marcu 1999 roku Chris Farrar zadał pytanie jednemu ze swoich deweloperów, które spowodowały, że zbadał część standardu SQL, który Myślałem, że rozumiem . Chris znalazł pewne różnice między ogólne zrozumienie i rzeczywiste brzmienie specyfikacji.

I tak dalej. Myślę, że wystarczy Celko.

C. J. Date on SQL nulls

C. J. Date jest bardziej radykalny w odniesieniu do Null: unikaj Null w SQL, kropka. W rzeczywistości, Rozdział 4 jego SQL i teoria relacyjna: jak pisać dokładne Kod SQL nosi tytuł " nie Duplikaty, bez NULL", z podrozdziałami "4.4 co jest nie tak z Null?" i " 4.5 unikanie Null w SQL "(kliknij na link: dzięki Google Books można czytać niektóre strony on-line).

Fabian Pascal on SQL NULLs

Z its praktyczne zagadnienia zarządzania bazami danych-odniesienie dla myślącego praktykującego (brak fragmentów on-line, sorry):

10.3 Praktyczne Implikacje

10.3.1 SQL NULLs

... SQL cierpi na problemy związane z 3VL, a także z wieloma dziwactwa, komplikacje, kontrintuitywność i jawne błędy [10, 11]; wśród nich są następujące:

• funkcje agregujące (np. SUM (), AVG ()) ignorują null (z wyjątkiem COUNT ()).
• wyrażenie skalarne w tabeli bez wierszy jest niepoprawnie obliczane na NULL, zamiast na 0.
• wyrażenie "NULL = NULL" jest ewaluowane na NULL, ale w SQL jest faktycznie niepoprawne; jednak ORDER BY traktuje null jako równe (cokolwiek poprzedzają lub podążają za "regularnymi" wartościami, pozostaje dostawcy DBMS).
• wyrażenie " x nie jest NULL "nie jest równe" NOT(x jest NULL)", jak to ma miejsce w 2VL.

...

Wszystkie komercyjnie zaimplementowane dialekty SQL podążają za tym podejściem 3VL, a tym samym, nie tylko exibits te problemy, ale mają również implementację spefic problemy, które różnią się w zależności od produktów .

Może to zależy, ale myślałem, że NULL=NULL ewaluuje do NULL Jak większość operacji z NULL jako operandem.

To, że nie wiesz, czym są dwie rzeczy, nie znaczy, że są równe. Jeśli myślisz o NULL myślisz o "null" (string), to prawdopodobnie potrzebujesz innego testu równości, takiego jak Postgresql ' s IS DISTINCT FROM i IS NOT DISTINCT FROM

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

Wyrażenie różni się od wyrażenia

Wyrażenie nie różni się od wyrażenia

Dla wejść innych niż null, jest różny od tego samego jako operator. Jednakże, jeśli oba wejścia są null to zwraca false, a jeśli tylko jedno wejście jest null to zwraca true. Podobnie, IS NOT different FROM is identify to = dla wejść innych niż null, ale zwraca true, gdy oba wejścia są null, I false, gdy tylko jedno wejście jest null. Tak więc konstrukcje te skutecznie działają tak, jakby null były normalną wartością danych, a nie "nieznaną".

NULL nie jest równa niczym, nawet sobie. Moim osobistym rozwiązaniem do zrozumienia zachowania NULL jest unikanie używania go w jak największym stopniu :).

Pojęcie NULL jest co najmniej wątpliwe. Codd wprowadził model relacyjny i koncepcję NULL w kontekście (i zaproponował więcej niż jeden rodzaj NULL!) Jednak teoria relacyjna ewoluowała od czasu oryginalnych pism Codda: niektóre z jego propozycji zostały odrzucone (np. klucz podstawowy), a inne nigdy nie zostały zaakceptowane (np. operatory theta). We współczesnej teorii relacyjnej (naprawdę relacyjnej teorii, powinienem podkreślić) NULL po prostu nie istnieje. Zobacz Trzeci Manifest. http://www.thethirdmanifesto.com/

Język SQL cierpi na problem kompatybilności wstecznej. NULL znalazł swoją drogę do SQL i utknęliśmy z nim. Prawdopodobnie implementacja NULL W SQL jest błędna (implementacja SQL Server sprawia, że sprawy są jeszcze bardziej skomplikowane ze względu na opcję ANSI_NULLS).

Zalecam unikanie użycia kolumn NULLable w tabelach bazowych.

Chociaż może nie powinienem się kusić, chciałem tylko stwierdzić, że poprawki własne o tym jak NULL działa w SQL:

NULL = NULL ocenia do UNKNOWN.

UNKNOWN jest wartością logiczną.

NULL jest wartością danych.

Jest to łatwe do udowodnienia np.

SELECT NULL = NULL

Poprawnie generuje błąd w SQL serverze. Jeśli wynik byłby wartością danych, to spodziewalibyśmy się zobaczyć NULL, Jak sugerują niektóre odpowiedzi tutaj (błędnie).

Wartość logiczna UNKNOWN jest traktowana inaczej w SQL DML i SQL DDL odpowiednio.

W SQL DML, UNKNOWN powoduje usunięcie wierszy z resultset.

Na przykład:

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

INSERT odnosi sukces dla tego wiersza, mimo że warunek CHECK rozwiązuje się do NULL = NULL. Jest to spowodowane zdefiniowaniem w standardzie SQL - 92 ("ANSI"):

11.6 definicja ograniczenia tabeli

3)

Jeśli ograniczeniem tabeli jest sprawdzenie definicja ograniczenia, wtedy niech SC będzie warunek wyszukiwania natychmiast zawarte w ograniczenie kontroli definicja i niech T będzie nazwą tabeli zawarte w odpowiedniej tabeli deskryptor ograniczeń; tabela ograniczenie nie jest spełnione, jeżeli i tylko wtedy, gdy

EXISTS (SELECT * FROM T WHERE NOT (SC))

To prawda.

W prostym języku angielskim, nasz nowy wiersz powyżej otrzymuje "benefit of the doubt" o byciu UNKNOWN i może przejść.

W SQL DML, Reguła dla w 1999 roku w ramach programu "Horyzont 2020" w ramach programu "Horyzont 2020" w ramach programu "Horyzont 2020" zrealizowano]}

Warunek wyszukiwania jest stosowany do każdy rząd T. wynik gdzie klauzula jest tabelą tych wierszy T dla których wynik wyszukiwania warunek jest prawdziwy.

W prostym języku angielskim wiersze, które oceniają do {[6] } są usuwane z resultset.

W technet istnieje dobre wyjaśnienie, jak działają wartości null.

Null oznacza nieznany.

Dlatego wyrażenie Boolean

Value = null

Nie ocenia NA false, tylko na null, ale jeśli jest to końcowy wynik klauzuli where, to nic nie jest zwracane. Jest to praktyczny sposób, aby to zrobić, ponieważ zwracanie null byłoby trudne do poczęcia.

Jest to interesujące i bardzo ważne aby zrozumieć następujące:

Jeśli w zapytaniu mamy

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

I

• wartość=1
• @ param is null
• id = 123
• @anotherParam=123

Then

"value= @ param" ocenia do null
"@param is null " evaluates to true
"id= @ anotherParam" evaluates to true

Więc wyrażenie do oceny staje się

(null lub true) i true

Możemy pokusić się o stwierdzenie, że tutaj" null lub true " będzie oceniane do null i w ten sposób całe wyrażenie staje się null i wiersz nie zostanie zwrócony.

Ponieważ" null lub true " jest obliczane na true, co jest bardzo logiczne, ponieważ jeśli jeden z operandów jest true z operatorem Or, to bez względu na wartość drugiego operandu operacja zwróci true. Nie ma więc znaczenia, że drugi operand jest nieznany (null).

Więc w końcu mamy true=true i w ten sposób wiersz zostanie zwrócony.

Uwaga: Z ta sama krystalicznie czysta logika, którą "null lub true" ocenia na true, "null I true" ocenia NA null.

Update:
Ok, aby to zakończyć chcę dodać resztę tutaj też, co okazuje się dość zabawne w stosunku do powyższego.

" null lub false "ocenia na null," NULL I false " ocenia NA false. :)

Logika jest oczywiście nadal tak samo oczywiste, jak wcześniej.

MSDN ma ładny Opis Artykuł na temat null i logiki trzech stanów, które wywołują.

W skrócie, Specyfikacja SQL92 definiuje NULL jako Nieznany, a NUL używane w następujących operatorach powoduje nieoczekiwane wyniki dla niewtajemniczonych:

= 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

Ponieważ NULL oznacza "nieznana wartość" i dwie nieznane wartości nie mogą być sobie równe.

Więc jeśli według naszej logiki NULL N°1 jest równeNULL N°2, to musimy to jakoś powiedzieć:

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

Gdzie znana wartość -1 N°1 jest równa -1 N°2

Zamieszanie wynika z poziomu indrection (abstrakcji), który pochodzi z użycia NULL .

Wracając do analogii "co jest pod choinką", "nieznany" opisuje stan wiedzy o tym, co znajduje się w pudełku A.

Więc jeśli nie wiesz, co jest w pudełku A, mówisz, że jest "nieznane", ale to nie znaczy, że "nieznane" jest w pudełku. Coś innego niż nieznane jest w pudełku, być może jakiś przedmiot, lub prawdopodobnie nic nie jest w pudełko.

Podobnie, jeśli nie wiesz, co jest w polu B, możesz oznaczyć swój stan wiedzy na temat zawartości jako "nieznany".

Oto kicker: Twój stan wiedzy o polu A jest równy twojemu stanowi wiedzy o polu B . (Twój stan wiedzy w obu przypadkach to "Nieznany" lub "Nie wiem, co jest w pudełku".), Ale zawartość pudełek może być równa lub nie.

Wracając do SQL, najlepiej będzie, gdy będziesz mógł porównywać tylko wartości kiedy wiesz, czym są. niestety, Etykieta opisująca brak wiedzy jest przechowywana w samej komórce, więc jesteśmy kuszeni, aby użyć jej jako wartości. Ale nie powinniśmy używać tego jako wartości, ponieważ prowadziłoby to do " zawartość pudełka a równa zawartości pudełka B, gdy nie wiemy, co jest w pudełku A i / lub nie wiemy, co jest w pudełku B. (Logicznie, implikacja "jeśli nie wiem, co jest w polu A i jeśli nie wiem, co jest w polu B, to co jest w polu a = co jest w polu B" jest fałsz.)

Yay, Martwy Koń.

Pytanie:
Czy jedna nieznana równa się inna nieznana?
(NULL = NULL)
To pytanie jest czymś, na co nikt nie może odpowiedzieć, więc domyślnie ma wartość true lub false w zależności od ustawienia ansi_nulls.

Jednak pytanie:
Czy ta nieznana zmienna jest nieznana?
To pytanie jest zupełnie inne i można na nie odpowiedzieć prawdą.

NullVariable = null porównuje wartości
nullVariable to null porównuje stan zmiennej

Null jest nieznany w sql, więc nie możemy oczekiwać, że dwie niewiadome będą takie same.

Można jednak uzyskać takie zachowanie, ustawiając ANSI_NULLS na Off(domyślnie włączone) Możesz użyć = operator dla 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

Tylko dodatek do innych wspaniałych odpowiedzi:

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

Tutaj wszystkie odpowiedzi wydają się pochodzić z perspektywy CS, więc chcę dodać jedną z perspektywy dewelopera.

Dla programisty NULL jest bardzo przydatne. Odpowiedzi tutaj mówią, że NULL oznacza Nieznany, a może w teorii CS to prawda, nie pamiętam, minęło trochę czasu. W rzeczywistości jednak, przynajmniej z mojego doświadczenia, dzieje się to około 1% czasu. Pozostałe 99% stosuje się w przypadkach, gdy wartość nie jest nieznana, ale wiadomo, że jest nieobecna.

Dla przykład:

• Client.LastPurchase, dla nowego klienta. Nie wiadomo, wiadomo, że jeszcze nie dokonał zakupu.

• Przy użyciu ORM z tabelą dla klasy hierarchia mapowanie, niektóre wartości nie są po prostu mapowane dla pewnych klas.

• Podczas mapowania struktura drzewa korzeń zwykle będzie miał Parent = NULL

• I wiele innych...

Jestem pewien, że większość programistów w pewnym momencie napisała WHERE value = NULL, nie uzyskali żadnych wyników i w ten sposób dowiedzieli się o składni IS NULL. Zobacz ile głosów ma to pytanie i te powiązane.

Bazy danych SQL są narzędziem i powinny być zaprojektowane w sposób, który jest najłatwiejszy do zrozumienia dla ich użytkowników.