Почему NULL = NULL оценивает значение false на сервере SQL

В SQL-сервере, если у вас есть nullParam=NULL в предложении where, он всегда вычисляет значение false. Это противоречиво и вызвало много ошибок. Я понимаю, что ключевые слова IS NULL и IS NOT NULL - это правильный способ сделать это. Но почему SQL-сервер ведет себя таким образом?

ОТВЕТЫ

Ответ 1

Подумайте о нулевом значении как "неизвестном" в этом случае (или "не существует" ). В любом из этих случаев вы не можете сказать, что они равны, потому что вы не знаете значения ни одного из них. Итак, null = null вычисляет не true (false или null, в зависимости от вашей системы), потому что вы не знаете значений, чтобы сказать, что они равны. Это поведение определено в стандарте ANSI SQL-92.

EDIT: Это зависит от настройки ansi_nulls. если у вас отключено ANSI_NULLS, этот показатель будет равен true. Выполните следующий код для примера...

set ansi_nulls off

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


set ansi_nulls ON

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

Ответ 2

Сколько лет Фрэнку? Я не знаю (null).

Сколько лет Ширли? Я не знаю (null).

Есть ли у Фрэнка и Ширли одинаковый возраст?

Правильный ответ должен быть "Я не знаю" (null), а не "нет", поскольку Фрэнк и Ширли могут быть одного возраста, мы просто не знаем.

Ответ 3

Здесь я надеюсь уточнить мою позицию.

То, что NULL = NULL оценивается как FALSE, неверно. Хакер и Мистер правильно ответили NULL. Вот почему. Девэйн Кристенсен написал мне в комментарии Скотту Айви:

Начиная с декабря, давайте использовать сезонный пример. У меня есть два подарка под елкой. Теперь скажите мне, если у меня есть два одинаковых или нет.

Они могут быть разными или равными, вы не знаете, пока не откроете оба подарка. Кто знает? Вы пригласили двух людей, которые не знают друг друга и оба сделали вам один и тот же подарок - редкий, но не невозможный §.

Таким образом, вопрос: эти два НЕИЗВЕСТНЫХ представляют одинаково (равно, =)? Правильный ответ: НЕИЗВЕСТНО (то есть, NULL).

Этот пример был призван продемонстрировать, что ".. (false или null, в зависимости от вашей системы).." является правильным ответом - это не так, только NULL является правильным в 3VL (или вы можете принять систему, которая дает неправильные ответы?)

Правильный ответ на этот вопрос должен подчеркнуть следующие два момента:

  • трехзначная логика (3VL) нелогична (см. бесчисленное множество других вопросов по этому вопросу в Stackoverflow и на других форумах, чтобы убедиться в этом);
  • СУБД на основе SQL часто не уважают даже 3VL, иногда они дают неправильные ответы (как утверждают первоначальные авторы, SQL Server в этом случае).

Поэтому я повторяю: SQL не имеет смысла заставлять интерпретировать рефлексивное свойство равенства, которое утверждает, что:

for any x, x = x §§ (на простом английском языке: независимо от универсума дискурса, "вещь" всегда равна себе).

.. в 3VL (TRUE, FALSE, NULL). Ожидание людей будет соответствовать 2VL (TRUE, FALSE, что даже в SQL действительно для всех других значений), то есть x = x всегда оценивается как TRUE, для любого возможного значения x - без исключений.

Также обратите внимание, что значения NULL являются допустимыми "ненулевыми значениями" (как утверждают их апологеты), которые можно назначать как значения атрибутов (??) как часть переменных отношения. Таким образом, они являются приемлемыми значениями каждого типа (домена), а не только типа логических выражений.

И это была моя точка зрения: NULL, как значение, "странный зверь". Без эвфемизма я предпочитаю говорить: ерунда.

Я думаю, что эта формулировка намного более ясна и менее спорна - извините за мое плохое знание английского языка.

Это только одна из проблем NULL. Лучше избегать их полностью, когда это возможно.

§ мы обеспокоены ценностями здесь, поэтому тот факт, что два подарка всегда являются двумя разными физическими объектами, не является обоснованным возражением; если вы не уверены, извините, это не то место, чтобы объяснить разницу между значением и семантикой "объекта" (Реляционная алгебра имеет семантику значения с самого начала - см. принцип информации Codd; я думаю, что некоторые разработчики СУБД SQL не даже не заботится об общей семантике).

§§ насколько мне известно, это аксиома, принятая (в той или иной форме, но всегда интерпретируемая в 2VL) с древности и именно потому , что она настолько интуитивна. 3VLs (в действительности это семейство логик) - это гораздо более свежая разработка (но я не уверен, когда она была впервые разработана).

Примечание: если кто-то представит типы Bottom, Unit и Option как попытку оправдать значения NULL в SQL, я буду убежден только после довольно подробного изучения, которое покажет, как реализации SQL с NULL имеют систему звукового типа, и, наконец, прояснит, что такое NULL (эти "значения-не-совсем-значения").

В дальнейшем я процитирую некоторых авторов. Любая ошибка или упущение, вероятно, принадлежит мне, а не авторам оригинала.

Джо Селко о SQL NULL

Я вижу, Джо Селко часто цитируется на этом форуме. Видимо, он очень уважаемый автор здесь. Итак, я сказал себе: "Что он пишет о SQL NULL? Как он объясняет NULL многочисленные проблемы?". У одного из моих друзей есть версия электронной книги Joe Celko SQL для умников: расширенное программирование на 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. Избегание пустых значений из программ хоста 197
6.10. Замечание о множественных значениях NULL 198
10.1 ЕСТЬ НЕДЕЙСТВИТЕЛЬНО Предикат 241
10.1.1 Источники NULL 242
...

и так далее. Это звучит как "неприятный особый случай" для меня.

Я рассмотрю некоторые из этих случаев с выдержками из этой книги, пытаясь ограничиться основным, по причинам авторского права. Я думаю, что эти цитаты подпадают под доктрину "добросовестного использования", и они могут даже стимулировать покупку книги - так что я надеюсь, что никто не будет жаловаться (в противном случае мне придется удалить большую часть, если не все). Кроме того, я буду воздерживаться от сообщения фрагментов кода по той же причине. Извини за это. Купите книгу, чтобы прочитать о данных рассуждениях.

Номера страниц между круглыми скобками в дальнейшем.

Ограничение NOT NULL (11)

Наиболее важным ограничением столбца является NOT NULL, которое запрещает использование NULL в столбце. Используйте это ограничение регулярно и снимайте его только тогда, когда у вас есть веская причина. Это поможет вам избежать осложнений значений NULL при выполнении запросов к данным.

Это не ценность; это маркер, который содержит место, куда может пойти значение.

Опять эта ерунда "ценность, но не совсем ценность". Остальное мне кажется вполне разумным.

(12)

Короче говоря, NULL вызывают много нерегулярных функций в SQL, которые мы обсудим позже. Лучше всего запоминать ситуации и правила для NULL, когда вы не можете их избежать.

По поводу SQL, NULL и бесконечности:

(104) ГЛАВА 3: ЧИСЛЕННЫЕ ДАННЫЕ В SQL

SQL не принял модель IEEE для математики по нескольким причинам.

...

Если бы правила IEEE для математики были разрешены в SQL, то нам понадобились бы правила преобразования типов для бесконечного числа и способ представления бесконечного точного числового значения после преобразования. У людей достаточно проблем с NULL, поэтому давайте не будем туда идти.

Реализации SQL не определились с тем, что на самом деле означает NULL в определенных контекстах:

3.6.2. Экспоненциальные функции (116)

Проблема в том, что логарифмы не определены, когда (x <= 0). Некоторые реализации SQL возвращают сообщение об ошибке, некоторые возвращают NULL и DB2/400; версия 3, выпуск 1 вернул * NEGINF (сокращение от "минус бесконечность") в качестве результата.

Джо Селко цитирует Дэвида Макговерана и СиДжея Дейта:

6 NULL: отсутствуют данные в SQL (185)

В своей книге "Руководство по Sybase и SQL Server" Дэвид МакГоверан и СиДжей Дейт сказал: "Это мнение авторов, что NULL, по крайней мере в том виде, в котором они в настоящее время определены и реализованы в SQL, гораздо сложнее, чем их стоит, и их следует избегать; они демонстрируют очень странное и противоречивое поведение и могут стать источником ошибок и путаницы (обратите внимание, что эти комментарии и критические замечания относятся к любой системе, поддерживающей значения NULL в стиле SQL, а не только к SQL Server). "

NULL как наркомания:

(186/187)

В остальной части этой книги я буду убеждать вас не использовать их, что может показаться противоречивым, но это не так. Думайте о NULL как о наркотике; используйте это правильно, и это работает для вас, но злоупотребляйте этим, и это может разрушить все. Ваша лучшая политика - избегать значений NULL, когда вы можете, и использовать их правильно, когда это необходимо.

Мое единственное возражение здесь состоит в том, чтобы "использовать их правильно", что плохо взаимодействует с определенным поведением реализации.

6.5.1 NULL в предикатах подзапроса (191/192)

Люди забывают, что подзапрос часто скрывает сравнение с NULL. Рассмотрим эти две таблицы:

...

Результат будет пустым. Это нелогично, но правильно.

(разделитель)

6.5.2 Стандартные решения SQL (193)

SQL-92 решил некоторые проблемы 3VL (трехзначной логики), добавив новый предикат в форме:

<условие поиска> IS [NOT] TRUE | ЛОЖЬ | НЕИЗВЕСТНЫЙ

Но UNKNOWN сам по себе является источником проблем, поэтому CJ Date в своей книге, цитируемой ниже, рекомендуется в главе 4.5. Как избежать пустых значений в SQL:

  • Не используйте ключевое слово НЕИЗВЕСТНО в любом контексте.

Прочитайте "ВНУТРИ" на НЕИЗВЕСТНОМ, также связанном ниже.

6,8 NULL и языки хоста (194)

Однако вы должны знать, как обрабатываются значения NULL, когда они должны быть переданы хост-программе. Ни один стандартный хост-язык, для которого определено встраивание, не поддерживает NULL, что является еще одной веской причиной избегать их использования в схеме базы данных.

(разделитель)

6.9. Советы по проектированию для NULL (195)

Рекомендуется объявлять все ваши базовые таблицы с ограничениями NOT NULL для всех столбцов, когда это возможно. NULL сбивают с толку людей, которые не знают SQL, а NULL стоят дорого.

Возражение: NULL сбивает с толку даже людей, которые хорошо знают SQL, см. Ниже.

(195)

НУЛЕВЫХ следует избегать в ИНОСТРАННЫХ КЛЮЧАХ. SQL допускает это отношение "выгоды от сомнения", но может привести к потере информации в запросах, которые включают в себя объединения. Например, учитывая код номера детали в Inventory, на который ссылается таблица FOREIGN KEY в таблице Orders, у вас будут проблемы с получением списка деталей, имеющих NULL. Это обязательные отношения; Вы не можете заказать деталь, которая не существует.

(разделитель)

6.9.1. Избегание пустых значений из программ хоста (197)

Вы можете избежать помещения пустых значений в базу данных из программ хоста с некоторой дисциплиной программирования.

...

  1. Определите влияние отсутствующих данных на программирование и отчетность: числовые столбцы с NULL являются проблемой, потому что запросы, использующие агрегатные функции, могут давать вводящие в заблуждение результаты.

(разделитель)

(227)

SUM() пустого набора всегда равно NULL. Одна из наиболее распространенных ошибок программирования, допущенных при использовании этого трюка, заключается в написании запроса, который может вернуть более одной строки. Если вы не думали об этом, вы могли бы написать последний пример как:...

(разделитель)

10.1.1 Источники NULL (242)

Важно помнить, где могут быть значения NULL. Они больше, чем просто возможное значение в столбце. Агрегатные функции для пустых множеств, OUTER JOIN, арифметические выражения с NULL и операторы OLAP возвращают NULL. Эти конструкции часто отображаются в виде столбцов в VIEW.

(разделитель)

(301)

Другая проблема с NULL обнаруживается при попытке преобразовать предикаты IN в предикаты EXISTS.

(разделитель)

16.3. Функции предиката и экстремума ALL (313)

Поначалу нелогично, что эти два предиката не совпадают в SQL:

...

Но вы должны помнить правила для функций экстремумов - они отбрасывают все NULL перед возвратом больших или меньших значений. Предикат ALL не пропускает NULL, поэтому вы можете получить их в результатах.

(разделитель)

(315)

Однако определение в стандарте сформулировано отрицательно, так что значения NULL получают преимущество сомнения....

Как видите, хорошей идеей является избегать значений NULL в ограничениях UNIQUE.

Обсуждение GROUP BY:

NULL обрабатываются так, как будто все они равны друг другу, и образуют свою собственную группу. Затем каждая группа сокращается до одной строки в новой таблице результатов, которая заменяет старую.

Это означает, что для предложения GROUP BY NULL = NULL не оценивается как NULL, как в 3VL, но оценивается как TRUE.

Стандарт SQL сбивает с толку:

ORDER BY и NULL (329)

Является ли значение ключа сортировки, равное NULL, большим или меньшим, чем значение, отличное от NULL, определяется реализацией, но...

... Есть продукты SQL, которые делают это в любом случае.

В марте 1999 года Крис Фаррар поднял вопрос от одного из своих разработчиков, который заставил его изучить часть стандарта SQL, которую, как мне показалось, я понял. Крис обнаружил некоторые различия между общим пониманием и реальной формулировкой спецификации.

И так далее. Я думаю, что достаточно Celko.

Дата CJ на пустых значениях SQL

CJ Date более радикально относится к NULL: избегайте NULL в SQL, точка. Фактически, глава 4 его теории SQL и реляционной теории: как писать точный код SQL называется "NO DUPLICATES, NO NULLS", с подразделами "4.4. Что не так с NULL?" и "4.5 Избегание пустых значений в SQL" (перейдите по ссылке: благодаря Google Книгам вы можете читать некоторые страницы в режиме онлайн).

Фабиан Паскаль о пустых значениях SQL

Из практических вопросов по управлению базами данных - справочник для практикующего мышления (нет выдержек в Интернете, извините):

10.3 Практические последствия

10.3.1. SQL NULL

... SQL страдает от проблем, присущих 3VL, а также от многих изысков, сложностей, нелогичности и прямых ошибок [10, 11]; среди них есть следующие:

  • Агрегатные функции (например, SUM(), AVG()) игнорируют NULL (за исключением COUNT()).
  • Скалярное выражение в таблице без строк неправильно оценивается как NULL вместо 0.
  • Выражение "NULL = NULL" оценивается как NULL, но фактически недопустимо в SQL; тем не менее ORDER BY обрабатывает NULL как равные (независимо от того, предшествуют они или следуют "обычным" значениям, остается поставщик СУБД).
  • Выражение "x IS NOT NULL" не равно "NOT (x IS NULL)", как в случае 2VL.

...

Все коммерчески реализуемые диалекты SQL следуют этому подходу 3VL, и, таким образом, они не только демонстрируют эти проблемы, но также имеют специфические проблемы реализации, которые различаются в разных продуктах.

Ответ 4

То, что вы не знаете, что такое две вещи, не означает, что они равны. Если, когда вы думаете о NULL вы думаете о "NULL" (строке), то вам, вероятно, нужен другой тест на равенство, такой как Postgresql IS DISTINCT FROM И IS NOT DISTINCT FROM

Из документов PostgreSQL на тему "Функции и операторы сравнения"

выражение IS DISTINCT FROM выражения

выражение IS NOT DISTINCT FROM выражения

Для ненулевых входных данных IS DISTINCT FROM аналогичен оператору <>. Тем не менее, если оба входа имеют значение null, он возвращает false, а если только один вход имеет значение null, он возвращает true. Точно так же IS NOT DISTINCT FROM идентична = для ненулевых входов, но возвращает true, если оба входа имеют значение null, и false, если только один вход имеет значение null. Таким образом, эти конструкции эффективно действуют так, как если бы null был обычным значением данных, а не "неизвестным".

Ответ 5

Возможно, это зависит, но я думал, что NULL=NULL оценивает NULL как и большинство операций с NULL в качестве операнда.

Ответ 6

Понятие NULL сомнительно, мягко говоря. Codd представила реляционную модель и концепцию NULL в контексте (и предложила более одного вида NULL!). Однако реляционная теория развилась с оригинальных текстов Codd: с тех пор некоторые из его предложений были отброшены (например, первичный ключ) и другие никогда не попадались (например, тета-операторы). В современной реляционной теории (по-настоящему реляционной теории, я должен подчеркнуть) NULL просто не существует. См. "Третий манифест". http://www.thethirdmanifesto.com/

Язык SQL страдает проблемой обратной совместимости. NULL нашел свой путь в SQL, и мы застряли с ним. Возможно, реализация NULL в SQL является ошибочной (реализация SQL Server делает вещи еще более сложными из-за ее опции ANSI_NULLS).

Я рекомендую избегать использования столбцов NULLable в базовых таблицах.

Хотя, возможно, я не должен испытывать соблазнов, я просто хотел утверждать свои собственные исправления о том, как NULL работает в SQL:

NULL= NULL оценивается как UNKNOWN.

UNKNOWN является логическим значением.

NULL - значение данных.

Это легко доказать, например.

SELECT NULL = NULL

правильно генерирует ошибку в SQL Server. Если результатом было значение данных, мы ожидаем увидеть NULL, поскольку некоторые ответы здесь (ошибочно) предполагают, что мы будем.

Логическое значение UNKNOWN обрабатывается по-разному в SQL 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 - имя таблицы включены в соответствующую таблицу дескриптор ограничения; стол ограничение не выполняется, если и только если

EXISTS (ВЫБРАТЬ * ОТ Т ГДЕ НЕ (SC))

истинно.

Внимательно прочитайте это, следуя логике.

На простом английском языке наша новая строка выше дает "выгоду от сомнений" о том, что она UNKNOWN и разрешена для прохождения.

В SQL DML правило для предложения WHERE намного проще:

Условие поиска применяется к каждая строка T. Результат предложение представляет собой таблицу этих строк T для которого результат поиска условие истинно.

На простом английском языке строки, которые оцениваются до UNKNOWN, удаляются из набора результатов.

Ответ 7

В technet есть хорошее объяснение того, как работают нулевые значения.

Нуль означает неизвестное.

Следовательно, булево выражение

value = null

не оценивает значение false, он вычисляет значение null, но если это конечный результат предложения where, то ничего не возвращается. Это практический способ сделать это, так как возвращение null было бы трудно представить.

Интересно и очень важно понимать следующее:

Если в запросе мы имеем

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

и

  • value = 1
  • @param null
  • id = 123
  • @anotherParam = 123

то

"value = @param" оценивается как null "@param is null" оценивается как true | "id = @anotherParam" оценивается как true

Итак, выражение, которое нужно оценить, становится

(null или true) И true

У нас может возникнуть соблазн подумать, что здесь "null или true" будет оцениваться как null, и, таким образом, все выражение станет null и строка не будет возвращена.

Это не так. Зачем?

Потому что "null или true" оценивается как true, что очень логично, так как если один операнд является истинным с Or-operator, то независимо от значения другого операнда операция вернет true. Таким образом, не имеет значения, что другой операнд неизвестен (null).

Итак, мы, наконец, имеем true = true и, следовательно, строка будет возвращена.

Примечание: с той же кристально чистой логикой, что "null или true" оценивается как true, "null И true" оценивается как null.

Update:
Хорошо, просто для того, чтобы закончить это, я хочу добавить сюда и остальные, которые выглядят довольно забавно по отношению к вышеизложенному.

"null Или false" оценивается как null, "null И false" оценивается как false.:)

Логика, конечно же, остается очевидной, как и прежде.

Ответ 8

NULL не равен ничему, даже самому себе. Мое личное решение для понимания поведения NULL заключается в том, чтобы не использовать его как можно больше:).

Ответ 9

MSDN имеет приятную описательную статью об ошибках и три логики состояния, которые они порождают.

Короче говоря, спецификация SQL92 определяет NULL как неизвестную, а NUL, используемый в следующих операциях, вызывает непредвиденные результаты для непосвященных:

= 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

Ответ 10

Потому что NULL означает "неизвестное значение", а два неизвестных значения не могут быть равны.

Итак, если наша логика NULL N ° 1 равна NULL N ° 2, то мы должны сказать, что так или иначе:

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

где известное значение -1 N ° 1 равно -1 N ° 2

Ответ 11

Путаница возникает из уровня косвенности (абстракции), которая возникает из-за использования NULL.

Возвращаясь к аналогии "что под елкой", "Неизвестный" описывает состояние знания о том, что находится в ящике А.

Итак, если вы не знаете, что в Box A, вы говорите это "Неизвестно", но это не значит, что "Неизвестный" находится внутри коробки. Что-то другое, кроме неизвестного, находится в поле, возможно, какой-то объект, или, возможно, ничего не находится в коробке.

Аналогично, если вы не знаете, что в Box B, вы можете обозначить свое состояние знания о содержимом как "Неизвестное".

Итак, вот кикер: ваше состояние знания о Box A равно вашему состоянию знаний о Box B. (Ваше состояние знания в обоих случаях "Неизвестно" или "Я не знаю, что в коробке".) Но содержимое ящиков может быть или не быть равным.

Возвращаясь к SQL, в идеале вы должны иметь возможность сравнивать значения, когда знаете, что они собой представляют. К сожалению, ярлык, описывающий недостаток знаний, хранится в самой ячейке, поэтому мы пытаемся использовать его в качестве значения. Но мы не должны использовать это как ценность, потому что это приведет к тому, что "содержимое Box A будет равно содержимому Box B, когда мы не знаем, что в Box A и/или мы не знаем, что в Box B. (Логически, импликация "если я не знаю, что в Box A, и если я не знаю, что в Box B, то что в Box A = What in Box B" является ложным.)

Yay, Dead Horse.

Ответ 12

Вопрос:
Неизвестно ли одно неизвестное? (NULL = NULL)
Этот вопрос - это то, на что никто не может ответить, поэтому он по умолчанию имеет значение true или false в зависимости от настройки ansi_nulls.

Однако вопрос:
Неизвестна неизвестная переменная?
Этот вопрос совсем другой, и на него можно ответить с истинным.

nullVariable = null сравнивает значения nullVariable - значение null, сравнивающее состояние переменной

Ответ 13

Все ответы здесь, кажется, приходят с точки зрения CS, поэтому я хочу добавить один с точки зрения разработчика.

Для разработчика NULL очень полезен. Ответы здесь говорят, что NULL означает неизвестный, и, возможно, в теории CS это правда, не помню, это было давно. В реальной разработке, хотя, по моему опыту, это происходит примерно в 1% случаев. Остальные 99% используются для случаев, когда значение не UNKNOWN, но оно, как известно, не имеет значения.

Например:

  • Client.LastPurchase, для нового клиента. Не известно, известно, что он еще не совершил покупку.

  • При использовании ORM с отображением " Таблица на иерархию классов" некоторые значения просто не отображаются для определенных классов.

  • При отображении древовидной структуры корень обычно имеет Parent = NULL

  • И многое другое...

Я уверен, что большинство разработчиков в какой-то момент написали WHERE value = NULL, не получили никаких результатов, и как они узнали о синтаксисе IS NULL. Посмотрите, сколько голосов имеют этот вопрос и связанные с ним.

Базы данных SQL являются инструментом, и они должны быть спроектированы так, чтобы их пользователям было проще понять.

Ответ 14

null неизвестно в sql, поэтому мы не можем ожидать, что два неизвестных будут такими же.

Однако вы можете получить это поведение, установив ANSI_NULLS в Off (его по умолчанию) Вы сможете использовать оператор = для нулей

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

Ответ 15

Просто добавление к другим замечательным ответам:

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

Ответ 16

Если вы ищете выражение, возвращающее true для двух NULL, вы можете использовать:

SELECT 1 
WHERE EXISTS (
    SELECT NULL
    INTERSECT
    SELECT NULL
)

Это полезно, если вы хотите скопировать данные из одной таблицы в другую.

Ответ 17

Вы работаете на правительство, регистрируя информацию о гражданах. Это включает в себя национальный идентификатор для каждого человека в стране. Около 40 лет назад у дверей церкви остался ребенок, никто не знает, кто их родители. Этот идентификационный номер отца NULL. Два таких человека существуют. Подсчитайте людей, которые имеют один и тот же идентификатор отца, по крайней мере, с одним другим человеком (людьми, которые являются братьями и сестрами). Ты тоже считаешь этих двоих?

Ответ - нет, вы не знаете, потому что мы не знаем, являются ли они братьями и сестрами или нет.

Предположим, у вас нет опции NULL, и вместо этого вы используете какое-то заранее определенное значение для представления "неизвестного", возможно, пустую строку или число 0 или символ * и т.д. Тогда в ваших запросах будет иметь значение * = *, 0 = 0, и '' = '' и т.д. Это не то, что вы хотите (в соответствии с примером выше), и как вы часто можете забыть об этих случаях (пример выше - это очевидный случай за пределами обычной повседневной жизни). размышляя), тогда вам нужен язык, чтобы помнить, что NULL = NULL не соответствует действительности.

Голь на выдумки хитра.