SQLサーバーでNULL = NULLがfalseと評価されるのはなぜですか

SQLサーバーnullParam=NULLでは、where句を使用 している場合、常にfalseと評価されます。これは直観に反しており、多くのエラーを引き起こしています。IS NULLとIS NOT NULLキーワードが正しい方法であることを理解しています。しかし、なぜSQLサーバーはこのように動作するのでしょうか。

その場合、ヌルは「不明」（または「存在しない」）と考えてください。どちらの場合も、どちらの値も分からないため、等しいとは言えません。したがって、null = nullはtrueではない（システムによってはfalseまたはnull）と評価されます。これは、値が等しいと言う値がわからないためです。この動作は、ANSI SQL-92標準で定義されています。

編集：これはansi_nulls設定に依存します。ANSI_NULLSがオフの場合、これは真と評価されます。例として次のコードを実行してください...

set ansi_nulls off

if null = null
    print 'true'
else
    print 'false'


set ansi_nulls ON

if null = null
    print 'true'
else
    print 'false'

フランクは何歳ですか？わかりません（null）。

シャーリーは何歳ですか？わかりません（null）。

フランクとシャーリーは同じ年齢ですか？

正解は「いいえ」ではなく、「私は知らない」（null）である必要があります。フランクとシャーリーは同じ年齢である可能性があるため、単に知りません。

ここで私の立場を明確にしたいと思います。

そのNULL = NULL評価FALSEは間違っています。ハッカーとミスターは正しく答えましたNULL。これが理由です。Dewayne ChristensenがScott Iveyへのコメントで私に書いた：

12月なので、季節の例を使用してみましょう。ツリーの下に2つのプレゼントがあります。さて、あなたは私が同じものを2つ持ったかどうか教えてください。

それらは異なる場合もあれば、等しい場合もあります。どちらか一方のプレゼントを開くまではわかりません。知るか？あなたはお互いを知らない2人の人を招待しましたが、どちらも同じ贈り物をしました-まれではありますが、不可能ではありません§。

したがって、質問：これら2つのUNKNOWNは同じ（等しい、=）ですか？正解は「不明」（つまりNULL）です。

この例は、「..（falseまたはnull、システムによって異なります）」が正しい答えであることを示すことを目的としています-正しくありません。3VL でのみ NULL正しいのです（または、間違った答えを与えるシステムを受け入れても大丈夫ですか？ ）

この質問に対する正しい答えは、この2つのポイントを強調する必要があります。

• 3値論理（3VL）は直観に反しています（確認するために、Stackoverflowや他のフォーラムでこの件に関する他の無数の質問を参照してください）。
• SQLベースのDBMSは、3VLさえ尊重しないことが多く、間違った回答をすることがあります（元の投稿者が主張するように、この場合SQL Serverが行います）。

繰り返しますが、SQLは、次のように述べている等値性の再帰的なプロパティを解釈するように強制することはできません。

for any x, x = x §§（平易な英語：談話の世界が何であれ、「もの」は常にそれ自体に等しい）

.. 3VLで（TRUE、FALSE、NULL）。人々の期待が2VL（に準拠してしまうTRUE、FALSEでもSQLに他のすべての値に対して有効である）、すなわちx = x 常にに評価され TRUEていない例外- xの任意の可能な値のため、。

また、NULLは有効な「非値」であり（その謝罪者はそれらを偽装しているため）、関係変数の一部として属性値（??）として割り当てることができます。したがって、これらは論理式のタイプだけでなく、すべてのタイプ（ドメイン）の許容値です。

そして、これは私のポイントでした：NULLは、価値として、「奇妙な獣」です。婉曲表現がなければ、私は言うのが好きです：ナンセンス。

この定式化ははるかに明確で論争の余地が少ないと思います-英語が下手なので申し訳ありません。

これはNULLの問題の1つにすぎません。可能であれば、完全に回避することをお勧めします。

§ここでは値に懸念があるため、2つのプレゼントが常に 2つの異なる物理オブジェクトであるという事実は有効な異論ではありません。確信がない場合は、申し訳ありませんが、値と「オブジェクト」のセマンティクスの違いを説明するのはここではありません（リレーショナル代数には、最初から値のセマンティクスがあります。コッドの情報原理を参照してください。SQLDBMSの実装者の中には、共通のセマンティクスについてさえ気にしないでください）。

§§私の知る限りでは、これは古代から受け入れられた公理です（何らかの形で、または常に2VLで解釈されます）。これはまさに直感的だからです。3VL（実際にはロジックのファミリーです）はより最近の開発です（ただし、いつ最初に開発されたかはわかりません）。

補足：誰かがSQL NULLを正当化する試みとしてBottom、Unit、およびOption型を紹介する場合、NULLを使用したSQL実装が適切な型システムをどのように備えているかを示し、最後に明確にする非常に詳細な調査を経て初めて確信します。 NULL（これらの「値ではなく値」）が実際に何であるか。

以下では、何人かの著者を引用します。エラーや脱落はおそらく私のものであり、元の作者のものではありません。

SQL NULLに関するJoe Celko

このフォーラムでJoe Celkoがよく引用されているのがわかります。どうやら彼はここで非常に尊敬されている著者です。それで、私は自分に言いました：「彼はSQL NULLについて何を書きましたか？彼はNULLの多くの問題をどのように説明しますか？」私の友人の1人がJoe CelkoのSQL for smarties（高度なSQLプログラミング、第3版）の電子ブックバージョンを持っています。どれどれ。

まず、目次。最も印象に残っているのは、NULLが言及された回数と最も多様なコンテキストです。

3.4算術とNULL 109
3.5値とNULLの変換110
3.5.1 NULLIF（）関数110
6 NULL：SQLでのデータの欠落185
6.4 NULLの比較190
6.5 NULLとロジック190
6.5.1サブクエリ述語でのNULL 191
6.5.2標準SQLソリューション193
6.6数学とNULL 193
6.7関数とNULL 193
6.8 NULLとホスト言語194
6.9 NULLの設計上のアドバイス195
6.9.1ホストプログラムからのNULLの回避197
6.10複数のNULL値に関する注意198
10.1 IS NULL述語241
10.1 1 NULLのソース242
...

等々。「厄介な特殊ケース」が鳴る。

私は、著作権の理由から、この本の抜粋を使用して、これらのケースのいくつかを取り上げ、自分自身を本質的なものに限定しようと試みます。これらの引用は「フェアユース」の法則に該当し、本を購入するよう刺激することさえできると思います。ですから、だれも文句を言わないようにしてください（そうしないと、全部ではないにしても、ほとんどを削除する必要があります）。さらに、同じ理由でコードスニペットの報告は控えさせていただきます。申し訳ありません。この本を購入して、詳細な推論について読んでください。

以下の括弧内のページ番号。

NOT NULL制約（11）

最も重要な列制約はNOT NULLであり、列でのNULLの使用を禁止します。この制約は日常的に使用し、正当な理由がある場合にのみ削除してください。データに対してクエリを実行するときに、NULL値の複雑さを回避するのに役立ちます。

値ではありません。値が移動する可能性のある場所を保持するマーカーです。

繰り返しになりますが、この「価値はありますが、かなりの価値はありません」というナンセンスです。残りは私にはかなり賢明なようです。

（12）

つまり、NULLはSQLに多くの不規則な機能を引き起こします。これについては後で説明します。最善の策は、NULLを回避できない状況とNULLのルールを記憶することです。

SQL、NULL、および無限の該当：

（104）第3章：SQLの数値データ

SQLは、いくつかの理由で数学のIEEEモデルを受け入れていません。

...

SQLで数学のIEEE規則が許可されている場合、無限の型変換規則と、変換後に無限の正確な数値を表す方法が必要になります。人々はNULLで十分な問題を抱えているので、そこに行かないでください。

SQL実装は、特定のコンテキストでNULLが実際に何を意味するかについては未定です。

3.6.2指数関数（116）

問題は、（x <= 0）の場合、対数が定義されていないことです。一部のSQL実装はエラーメッセージを返し、一部はNULLおよびDB2 / 400を返します。バージョン3リリース1は、その結果として* NEGINF（「負の無限大」の略）を返しました。

Joe CelkoがDavid McGoveranとCJ Dateを引用：

6 NULL：SQLでデータが欠落（185）

David McGoveranとCJ Dateは、著書 『A Guide to Sybase and SQL Server』で次のように述べています。それらは非常に奇妙で一貫性のない動作を示し、エラーと混乱の豊富な原因となる可能性があります。（これらのコメントと批判は、SQL Serverだけでなく、SQLスタイルのNULLをサポートするすべてのシステムに適用されることに注意してください。）

薬物中毒としてのヌル：

（186/187）

この本の残りの部分では、矛盾するように見えるかもしれませんが、使用しないようにお願いしますが、そうではありません。NULLをドラッグと考えてください。適切に使用すれば機能しますが、乱用するとすべてが台無しになってしまいます。可能な限りNULLを回避し、必要な場合はNULLを適切に使用することが最善のポリシーです。

ここでの私の唯一の異論は、「適切に使用する」ことです。これは、特定の実装動作と不適切に相互作用します。

6.5.1サブクエリ述語のNULL（191/192）

多くの場合、サブクエリはNULLとの比較を隠していることを忘れています。次の2つのテーブルについて考えてみます。

...

結果は空になります。これは直観に反していますが、正解です。

（セパレーター）

6.5.2標準SQLソリューション（193）

SQL-92は、次の形式の新しい述語を追加することにより、3VL（3値論理）の問題のいくつかを解決しました。

<検索条件> IS [NOT] TRUE | 誤り| わからない

しかし、UNKNOWN自体が問題の原因であるため、CJ Dateは、以下に引用する彼の著書で、4.5章で推奨されています。SQLでのNULLの回避：

• どのような状況でも、キーワードUNKNOWNを使用しないでください。

下記にリンクされているUNKNOWNの「ASIDE」をお読みください。

6.8 NULLとホスト言語（194）

ただし、NULLをホストプログラムに渡す必要がある場合は、NULLの処理方法を知っておく必要があります。埋め込みが定義されている標準のホスト言語はNULLをサポートしていません。これは、データベーススキーマでNULLを使用しないようにするもう1つの理由です。

（セパレーター）

6.9 NULLの設計アドバイス（195）

可能な限り、すべての列でNOT NULL制約を使用してすべてのベーステーブルを宣言することをお勧めします。NULLはSQLを知らない人を混乱させ、NULLは高価です。

異論：NULLは、SQLをよく知っている人でも混乱させます。以下を参照してください。

（195）

NULLはFOREIGN KEYで避けてください。SQLはこの「疑いの恩恵」関係を許可しますが、結合を含むクエリで情報の損失を引き起こす可能性があります。たとえば、OrdersテーブルによってFOREIGN KEYとして参照されるInventoryのパーツ番号コードを指定すると、NULLのあるパーツのリストを取得するときに問題が発生します。これは必須の関係です。存在しない部品は注文できません。

（セパレーター）

6.9.1ホストプログラムからのNULLの回避（197）

いくつかのプログラミング規則を使用して、ホストプログラムからデータベースにNULLを入力することを回避できます。

...

5. 不足しているデータがプログラミングとレポートに与える影響を特定する： 集計関数を使用したクエリは誤解を招く結果をもたらす可能性があるため、NULLのある数値列は問題です。

（セパレーター）

（227）

空のセットのSUM（）は常にNULLです。このトリックを使用するときに発生する最も一般的なプログラミングエラーの1つは、複数の行を返す可能性のあるクエリを記述することです。あなたがそれについて考えなかったなら、あなたは最後の例を次のように書いたかもしれません：...

（セパレーター）

10.1.1 NULLのソース（242）

NULLが発生する可能性のある場所を覚えておくことは重要です。これらは単なる列の可能な値ではありません。空のセットの集計関数、OUTER JOIN、NULLを含む算術式、およびOLAP演算子はすべてNULLを返します。これらの構成は、多くの場合、VIEW内の列として表示されます。

（セパレーター）

（301）

IN述部をEXISTS述部に変換しようとすると、NULLに関する別の問題が見つかります。

（セパレーター）

16.3 ALL述語および極値関数（313）

これらの2つの述語がSQLでは同じでないことは、最初は直観に反しています。

...

ただし、極値関数の規則を覚えておく必要があります。これらの関数は、大きい値または最小値を返す前にすべてのNULLを削除します。ALL述部はNULLをドロップしないため、結果でそれらを取得できます。

（セパレーター）

（315）

ただし、標準の定義は否定的に表現されているため、NULLは疑いの恩恵を受けます。...

ご覧のとおり、UNIQUE制約ではNULLを使用しないことをお勧めします。

GROUP BYについて議論する：

NULLは、すべてが互いに等しいかのように扱われ、独自のグループを形成します。その後、各グループは、古い結果テーブルを置き換える新しい結果テーブルの単一行に削減されます。

つまり、GROUP BY句の場合、NULL = NULLは3VLのようにNULLに評価されませんが、TRUEに評価されます。

SQL標準は混乱しています。

ORDER BYとNULL（329）

NULLのソートキー値が非NULL値より大きいか小さいかは実装定義ですが...

...どちらの方法でも実行できるSQL製品があります。

1999年3月、Chris Farrarが彼の開発者の1人から質問を持ち出し、私が理解していると思ったSQL標準の一部を調べさせました。クリスは、仕様の一般的な理解と実際の表現との間にいくつかの違いを発見しました。

等々。セルコで十分だと思います。

SQL NULLのCJ日付

CJ日付はNULLについてより過激です。SQLのNULLは避けてください。実際、彼のSQLとリレーショナル理論の第4章：正確なSQLコードの書き方は「重複なし、NULLなし」というタイトルで、副章は 「4.4 Nullの何が悪いのか？」および「4.5 SQLでのNULLの回避」（リンクをたどる：Googleブックスのおかげで、いくつかのページをオンラインで読むことができます）。

SQL NULLに関するFabian Pascal

データベース管理におけるその実用的な問題から-思考実践者のためのリファレンス（オンライン抜粋、申し訳ありません）：

10.3実質的な影響

10.3.1 SQL NULL

... SQLは、3VLに固有の問題だけでなく、多くの癖、複雑さ、直観に反する問題、および明白なエラーに悩まされています[10、11]。それらの中には次のものがあります：

• 集計関数（たとえば、SUM（）、AVG（））はNULLを無視します（COUNT（）を除く）。
• 行のないテーブルのスカラー式は、0ではなくNULLと誤って評価されます。
• 式「NULL = NULL」はNULLと評価されますが、SQLでは実際には無効です。しかし、ORDER BYはNULLを等しいものとして扱います（「通常の」値の前後にあるものはすべてDBMSベンダーに任されています）。
• 2VLの場合のように、「x IS NOT NULL」という表現は「NOT（x IS NULL）」と等しくありません。

...

商用実装されているすべてのSQL方言は、この3VLアプローチに従っているため、これらの問題を示しているだけでなく、製品ごとに異なる固有の実装問題があります。

多分それは依存するかもしれませんが、私はNULLをオペランドとして持つほとんどの演算が好きであるとNULL=NULL評価しNULLました。

2つが何であるかわからないからといって、それらが等しいとは限りません。NULLあなたが「NULL」（文字列）について考えるとき、おそらくPostgresqlのIS DISTINCT FROMANDのような別の同等性のテストが必要です。IS NOT DISTINCT FROM

「比較関数と演算子」に関するPostgreSQLドキュメントから

式IS DISTINCT FROM式

式IS NOT DISTINCT FROM式

null以外の入力の場合IS DISTINCT FROMは、<>演算子と同じです。ただし、両方の入力がnullの場合はfalseを返し、1つの入力のみがnullの場合はtrueを返します。同様に、null以外の入力のIS NOT DISTINCT FROM場合と同じです=が、両方の入力がnullの場合はtrueを返し、1つの入力のみがnullの場合はfalseを返します。したがって、これらの構造は、「不明」ではなく、nullが通常のデータ値であるかのように効果的に機能します。

NULLの概念は控えめに言っても疑問です。Coddは、関係モデルとNULLの概念をコンテキストで紹介しました（そして、複数の種類のNULLを提案し続けました！）ただし、関係理論はCoddの最初の執筆以来進化してきました。そして他の人は決して追いついていない（例えばシータ演算子）。現代の関係理論（真の関係理論、私は強調すべきです）では、NULLは単に存在しません。第三の宣言を参照してください。http://www.thethirdmanifesto.com/

SQL言語には、下位互換性の問題があります。NULLがSQLへの道を見つけ、私たちはそれで立ち往生しています。間違いなく、NULLSQL のの実装には欠陥があります（SQL Serverの実装は、そのANSI_NULLSオプションにより、事態をさらに複雑にします）。

ベーステーブルでNULL可能な列を使用しないことをお勧めします。

誘惑されるべきではないかもしれませんがNULL、SQLでどのように機能するかについて自分自身の修正を主張したかっただけです。

NULL=はにNULL評価されUNKNOWNます。

UNKNOWN 論理値です。

NULL データ値です。

これは簡単に証明できます。

SELECT NULL = NULL

SQL Serverでエラーを正しく生成します。結果がデータ値である場合、NULLここで（誤って）いくつかの回答が示すように、が表示されることを期待します。

UNKNOWNSQL DMLとSQL DDLでは、論理値の扱いがそれぞれ異なります。

SQL DMLではUNKNOWN、結果セットから行が削除されます。

例えば：

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ても、この行のは成功CHECKしNULL = NULLます。これは、SQL-92（ "ANSI"）標準で定義されています。

11.6テーブル制約の定義

3）

テーブル制約がチェック制約定義である場合、SCをチェック制約定義にすぐに含まれる検索条件とし、Tを対応するテーブル制約記述子に含まれるテーブル名にします。テーブルの制約が満たされないのは、

存在します（SELECT * FROM T WHERE NOT（SC））

本当です。

ロジックに従って、もう一度注意深く読んでください。

平易な英語で、上の新しい行にはUNKNOWN、存在することと合格することについての「疑いの利益」が与えられます。

SQL DMLでは、WHERE句のルールに従う方がはるかに簡単です。

検索条件はTの各行に適用されます。where句の結果は、検索条件の結果が真であるTの行のテーブルです。

プレーンな英語では、評価される行UNKNOWNは結果セットから削除されます。

technetでは、null値がどのように機能するかについての適切な説明があります。

nullは不明を意味します。

したがって、ブール式

値= null

falseと評価されず、nullと評価されますが、それがwhere句の最終結果である場合、何も返されません。nullを返すのは難しいので、これは実際的な方法です。

以下を理解することは興味深いことであり、非常に重要です。

クエリ内にある場合

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

そして

• 値= 1
• @paramはnullです
• id = 123
• @ anotherParam = 123

その後

"value = @ param"
はnullと評価されます"@param is null"はtrueと評価されます
"id = @ anotherParam"はtrueと評価されます

したがって、評価される式は

（nullまたはtrue）そしてtrue

ここで「null Or true」はnullと評価されるため、式全体がnullになり、行は返されないと考えたくなるかもしれません。

これはそうではありません。どうして？

「null Or true」は非常に論理的なtrueと評価されるため、一方のオペランドがOr演算子でtrueの場合、もう一方のオペランドの値に関係なく、操作はtrueを返します。したがって、他のオペランドが不明（null）であることは重要ではありません。

したがって、最終的にtrue = trueとなるため、行が返されます。

注：「null Or true」がtrueと評価されるのと同じ非常に明確なロジックで、「null And true」はnullと評価されます。

更新：
わかりました、それを完全にするために、残りもここに追加したいと思います。これは、上記に関して非常に楽しいことがわかりました。

「null Or false」はnullと評価され、「null And false」はfalseと評価されます。:)

もちろん、論理は以前と同じように自明です。

これNULLは、「不明な値」と2つの不明な値を同じにすることはできないためです。

したがって、ロジックに対してNULLN°1がNULLN°2 と等しい場合、どういうわけかそれを伝える必要があります。

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

ここで、既知の値-1N°1は-1N°2に等しい

ここでの答えはすべてCSの観点から来ているようですので、開発者の観点から1つ追加したいと思います。

開発者にとってNULLは非常に便利です。ここでの答えは、NULLは不明であることを意味し、CS理論では真実であることを覚えています。覚えていないのは、久しぶりです。しかし、実際の開発では、少なくとも私の経験では、それは時間の約1％です。残りの99％は、値が不明ではないが存在しないことがわかっている場合に使用されます。

例えば：

• Client.LastPurchase、新しいクライアントの場合。それは不明ではありません、彼がまだ購入していないことが知られています。

• クラス階層ごとのテーブルマッピングでORMを使用すると、一部の値が特定のクラスにマッピングされないだけです。

• ツリー構造をマッピングするとき、ルートは通常Parent = NULL

• などなど...

ほとんどの開発者は、ある時点でを書いてWHERE value = NULL、結果が得られなかったと確信しています。IS NULLます。構文です。この質問とリンクされた質問の投票数を確認してください。

SQLデータベースはツールであり、ユーザーが最も理解しやすい方法で設計する必要があります。

NULLはそれ自体ではなく、何にも等しくありません。NULLの動作を理解するための私の個人的な解決策は、NULLをできるだけ使用しないことです。

質問：
1つの未知数は別の未知数と等しいですか？
（NULL = NULL）
その質問は誰も答えることができないものなので、ansi_nulls設定に応じてデフォルトでtrueまたはfalseに設定されます。

しかし質問：
この未知の変数は未知ですか？
この質問はかなり異なり、trueで回答できます。

nullVariable = nullは値を比較しています
nullVariable is nullは変数の状態を比較しています

混乱は、NULLの使用から生じる間接性（抽象化）のレベルから生じます。。

「クリスマスツリーの下にあるもの」の類推に戻ると、「不明」はボックスAの内容に関する知識の状態を説明しています。

つまり、ボックスAの内容がわからない場合は、「不明」であると言いますが、「不明」がボックス内にあるという意味ではありません。不明以外のものがボックスに含まれている可能性があります。おそらく何らかのオブジェクトであるか、ボックスに何も含まれていない可能性があります。

同様に、ボックスBの内容がわからない場合は、内容に関する知識の状態を「不明」としてラベル付けできます。

だからここにキッカーがあります：ボックスAについてのあなたの知識の状態はボックスBについてのあなたの知識の状態と等しいですです。（どちらの場合も、あなたの知識の状態は「不明」または「箱の内容がわからない」です。）ただし、箱の内容は同じである場合とそうでない場合があります。

SQLに戻ると、理想的には、値が何であるかがわかっている場合にのみ値を比較できるはずです。残念ながら、知識の欠如を説明するラベルはセル自体に格納されているため、値として使用したくなります。ただし、「ボックスAの内容がわからない場合や、ボックスBの内容がわからない場合は、ボックスAの内容がボックスBの内容と同じになるため、値として使用しないでください。 （論理的には、「ボックスAの内容がわからない場合、およびボックスBの内容がわからない場合、ボックスAの内容=ボックスBの内容」は誤りです。）

イェイ、死んだ馬。

MSDNには、nullとそれが生成する3つの状態ロジックに関するわかりやすい記事があります。

つまり、SQL92の仕様ではNULLが不明と定義されており、次の演算子でNULLを使用すると、開始されていないユーザーに予期しない結果が生じます。

= 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

SQLではnullは不明であるため、2つの不明が同じであることは期待できません。

ただし、ANSI_NULLSをオフに設定することでその動作を得ることができます（デフォルトではオン）。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

あなたは、市民に関する情報を登録する政府のために働いています。これには、国内のすべての人の国民IDが含まれます。約40年前に子供が教会の玄関に残されました、両親が誰であるか誰も知りません。この人の父親IDはNULLです。そのような人が二人存在します。同じ父親IDを少なくとも1人の他の人（兄弟である人）と共有している人を数えます。あなたもそれら2つを数えますか？

答えは「いいえ」です。兄弟ではないかどうかはわかりません。

NULLオプションがないとします。代わりに、あらかじめ決められた値を使用して、「不明」を表します。空の文字列または数字の0または*文字などを使用します。クエリで* = * 、0 = 0、および「」=「」などです。これは（上記の例のように）必要なことではなく、これらのケースをしばしば忘れる可能性があります（上記の例は、通常の日常的な思考の外の明確な周辺ケースです） ）、それからあなたはあなたのために覚えていない言語が必要NULL = NULLです。それは真実ではありません。

必要は発明の母。

他の素晴らしい答えへの追加：

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

2つのNULLに対してtrueを返す式を探している場合は、次を使用できます。

SELECT 1 
WHERE EXISTS (
    SELECT NULL
    INTERSECT
    SELECT NULL
)

あるテーブルから別のテーブルにデータを複製する場合に役立ちます。

たとえば、case文のwhen句の等価性テストは、次のように変更できます。

XYZ = NULL 

に

XYZ IS NULL

空白と空の文字列をNULLと同等に扱いたい場合は、次のような等価テストもよく使用します。

(NULLIF(ltrim( XYZ ),'') IS NULL)