is_null или === null

Содержание

Что такое null и как с этим жить: сравнение с null в PHP, тонкости в приведении типов данных

В работе с любыми данными то и дело требуется как-то обозначить их отсутствие. Новички зачастую для этой цели используют значение false, которое, по сути, является не отсутствием данных, а определённым значением типа boolean. Для того, чтобы как-то помечать неопределённость или отсутствие данных, существует специальное значение null. Про false, null и прочее уже немало сказано и добавить что-то оригинальное крайне сложно. Но гораздо сложнее бывает найти баг, вызванный неочевидным поведением этих штуковин. Поэтому, вдохновлённый одним таким багом, самым элегантным в моём послужном списке, я решил написать маленькую шпаргалку на эту тему.

Перегружать пост интересными, но довольно-таки бесполезными определениями из Википедии я не стану. Вместо этого перейду сразу к делу и приведу цитату со страницы php.net, посвящённой null:

Специальное значение NULL представляет собой переменную без значения. NULL — это единственно возможное значение типа null. Переменная считается null, если:

  • ей была присвоена константа NULL.
  • ей еще не было присвоено никакого значения.
  • она была удалена с помощью unset().

До этого момента всё кажется простым, но чтобы так оставалось и дальше, при работе с null нужно придерживаться определённых правил.

Математические операции с null

Во всех математических операциях null ведёт себя аналогично int(0):

Проверка переменной на null

Чтобы точно узнать, что переменная содержит null (то есть, ничего не содержит), нужно использовать либо специальную функцию is_null() либо тождественное сравнение ===, а любые другие способы не подойдут:

Проверка null if-выражениях, а так же в функциях empty() и isset()

Тут переменные с null ведут себя абсолютно предсказуемо, как и любые другие ложные значения (которые в if-выражениях приводятся к false). Но нужно помнить, что это не гарантирует нам, что в переменной находится именно null:

Сравнение двух null

В PHP как гибкое, так и тождественное сравнение двух null всегда возвращает false, в отличие от многих других платформ, где сравнение двух неизвестностей возвращает так же неизвестность (то есть, null).

Поведение null при нетождественном сравнении с приведением типов данных

PHP разрешает сравнивать null-ы не только между собой, но и с другими типами данных. При этом не стоит забывать, что гибкое сравнение в php не является транзитивным, то есть, если два значения равны третьему по отдельности, не гарантирует их равенство между собой. Согласно таблицам приведения типов, гибкое сравнение null при помощи оператора == с разными значениями возвращает разные результаты:

Сравнение с null с помощью >, =, PHP -> JavaScript) поведение null может меняться.

Исследование null в JavaScript (а вместе с ним и загадочного undefined) заслуживает отдельной статьи. Главное отличие состоит в том, что, не смотря на приведение типов, null в JavaScript ничему не равен, кроме самого null и этого самого undefined, хотя в if-выражениях и срабатывает аналогично false. А при сравнении с числами он выдаёт ещё более забавные результаты, чем в PHP.

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

Простое правило при работе null, которое помогает избегать проблем

Вообще-то, не стоило читать этот пост. Держать в голове все эти нюансы, которые разные платформы трактуют по-разному, — неблагодарное занятие. Для того, чтобы избежать проблем с null нужно запомнить всего лишь одно правило:

Значения NULL ( ЕСТЬ NULL и ЕСТЬNULL())

NULL – отсутствующие значения.
Не путать с нулевым значением! NULL – это не число, не равно пробелу, пустой ссылке, Неопределено.

NULL – типообразующее значение, т.е. есть тип NULL и единственное значение этого типа.

NULL значения появляются в запросе в следующих ситуациях:
а) Внешнее соединение, при котором не было найдено соответствующей записи в другой таблице (при левом – во второй, при правом – в первой, при полном – в обоих)
б) Обращение к реквизитам элементов для группы и наоборот.
в) NULL в списке полей выборки (ВЫБРАТЬ)
г) Обращение к реквизитам для битой ссылки

ЕСТЬ NULL используется в операторе ВЫБРАТЬ (как бы проверя, что значение это есть пустое ( Значение ЕСТЬ NULL )):
Код 1C v 8.х
еще пример:
Код 1C v 8.х

Функция ЕСТЬNULL (значение, РезультатЕслиNULL) возвращает значение своего первого параметра, в случае если он не равен NULL, и значение второго параметра в противном случае
Является свернутым ВЫБОР…КОНЕЦ, но ЕСТЬNULL предпочтительнее.
Код 1C v 8.х
еще пример:
Код 1C v 8.х
В данном примере получаются все элементы справочника номенклатуры, после чего, для каждой номенклатуры из регистра накопления получаются текущие остатки. Т.к. для номенклатуры, по которой отсутствуют остатки, виртуальная таблица остатков не запись вернет, то в результате соединения в поле «УчетНоменклатурыОстатки.КоличествоОстаток» будут значения NULL для номенклатуры, по которой не было остатков. Для того чтобы вместо значения NULL в результате запроса присутствовало значение 0, мы использовали функцию ЕСТЬNULL(), которая осуществит желаемую замену.

ЕСТЬNULL отличается от ВЫБОР по следующим причинам:
а) При ЕСТЬNULL лучше читается запрос (проще)
б) При ЕСТЬNULL, если проверяется сложное выражение, то работает быстрее, поскольку вычисляется один раз
в) При ЕСТЬNULL выражение замены приводится к типу проверяемого выражения, если оно имеет тип Строка (длина) или Число (разрядность).

Нельзя проверять значения на NULL обычным равенством, потому что в SQL действует трехзначная логика – Истина, Ложь, NULL, и результатом такого сравнения будет UNKNOWN, что в 1С 8.0 аналогично ЛОЖЬ.
NULL <> 0, поэтому при левых внешних соединениях спр. Номенклатура с таблицами остатков, цен, Контрагентов со взаиморасчетами при отсутствии таких записей там будет NULL, который не равен 0. Лучшее решение – ЕСТЬNULL

is_null — Проверяет, является ли значение переменной равным NULL

(PHP 4 >= 4.0.4, PHP 5, PHP 7)

is_null — Проверяет, является ли значение переменной равным NULL

Описание

Проверяет, является ли значение данной переменной равным NULL .

Список параметров

Возвращаемые значения

Возвращает TRUE , если значение var равно null , или FALSE в противном случае.

Примеры

Пример #1 Пример использования is_null()

$foo = NULL ;
var_dump ( is_null ( $inexistent ), is_null ( $foo ));

Смотрите также

  • The NULL type
  • isset() — Определяет, была ли установлена переменная значением отличным от NULL
  • is_bool() — Проверяет, является ли переменная булевой
  • is_numeric() — Проверяет, является ли переменная числом или строкой, содержащей число
  • is_float() — Проверяет, является ли переменная числом с плавающей точкой
  • is_int() — Проверяет, является ли переменная переменной целочисленного типа
  • is_string() — Проверяет, является ли переменная строкой
  • is_object() — Проверяет, является ли переменная объектом
  • is_array() — Определяет, является ли переменная массивом

Is_null или === null?

Версия для печати

Конференция: Конференция iXBT.com (http://forum.ixbt.com/) Форум: Архив «Программирование» (http://forum.ixbt.com/? > URL: http://forum.ixbt.com/topic.cgi? > Время GMT +03. Даты в формате dd.mm.yyyy.
Константин_С , 21.03.2002 11:57
Для идентификации того, что значение не определено, в поле таблички (в данном случае речь идет об MS SQL 2000) можно хранить:

а) значения NULL;
б) другие значения в зависимости от логики приложения (например, для каждого типа поля — его нулевое/пустое значение: для числовых типов — нуль, для строковых — пустые строки и т.д.).

Вообще-то я с опаской отношусь к первому варианту, да и Microsoft, судя по их высказываниям, рекомендует минимизировать использование NULL. Но все-таки. Какие есть точки зрения, какие «за» и «против»?

1. Kid_Deceiver , 21.03.2002 12:33
Не знаю, что там MS выдумывает, а в стандарте так. Любят они над стандартами изгаляться

Добавление от 21-03-2002 12:34:

другие значения в зависимости от логики приложения (например, для каждого типа поля — его нулевое/пустое значение
Вот оный NULL и есть в каждом типе. И он между прочим, implementation-dependent.

2. Константин_С , 21.03.2002 12:52
Kid_Deceiver
А насчет «хорошего» и «плохого» стилей программирования? К какому из них можно отнести использование NULL (если, конечно, вопрос корректен)? Я просто хочу узнать, есть ли некие общепринятые тенденции, или каждый решает для себя сам, как поступать?
3. are , 21.03.2002 13:02
Константин_С
ты вообще разберись с логикой своего приложения.
два бизнес правила:
«Целочисленное поле N может принимать неопределенное значение»
и
«для поля N присваивать значение 0 если значение не определено «
две большие разницы.

Если у тебя поле может принимать неопределенное значение значит надо использовать NULL.

4. Kid_Deceiver , 21.03.2002 13:08
Константин_С
А насчет «хорошего» и «плохого» стилей программирования?
А причем тут стиль? Есть стандарт, на него и ориентируйся. Это и будет лучшим стилем. А то придется как-нибудь переность БД c MS-SQL на сервер, где MS-стиль не поддерживается и выйдет тебе «стиль» боком.

цитата: Константин_С:
А насчет «хорошего» и «плохого» стилей программирования? К какому из них можно отнести использование NULL (если, конечно, вопрос корректен)?

Этот спор ведется уже не один десяток лет Одни говорят, что привнесение трехзначной логики было огромным прорывом, другие — что величайшим промахом
По мне, так это дело вкуса и конкретной модели ВАШЕЙ предметной области.
И вообще это одна из тем для holy wars: расстановка фигурных скобок в C, Windows vs. Unix, C++ vs. C vs. MS SQL vs. Oracle vs. DB2 vs.

5. iamphet , 21.03.2002 13:29
6. Константин_С , 21.03.2002 13:43
are
ты вообще разберись с логикой своего приложения
Ну, вот тебе и на. Я ж не клевать меня попросил, а поделиться опытом.
7. Dmitri2 , 21.03.2002 13:57
Константин_С
У меня NULL вызывает проблемы когда использется запрос вида

select . from table1
where field1 like aram1

хочется чтобы если field1 — строка и param1 = ‘%’ то чтобы возвращались ВСЕ записи. Oracle взозвращает все записи где field1 is not null

и иногда запрос приходится делать некрасивый
select * from table1
where field1 is null or field1=»

Вообще IMHO NULL имеет смысл использовать довольно редко, особенно учитывая что стандартные визуальные контролы не дают пользователю возможности вводить NULL или проверять значение на NULL

8. KAE , 21.03.2002 14:00
Константин_С
Можно увидеть линк, где МС не рекомендует использовать NULL ?
9. Kid_Deceiver , 21.03.2002 14:07
Dmitri2
хочется чтобы если field1 — строка и param1 = ‘%’ то чтобы возвращались ВСЕ записи. Oracle взозвращает все записи где field1 is not null
Хочется ему. . Стандарт гласит все он правильно возвращает.
10. Константин_С , 21.03.2002 14:16
KAE
Можно увидеть линк, где МС не рекомендует использовать NULL ?
Я писал «рекомендует минимизировать использование NULL», а не то, что Вы подумали А фраза эта взята из «SQL Server Book Online»->закладка «Index»->ключевое словосочетание «null values» и под ним — «overview». Там, на страничке есть выделенное жирным «IMPORTANT», которое гласит «To minimize maintenance and possible effects on existing queries or reports, it is recommended that you minimize the use of null values. «
11. QZ , 21.03.2002 14:18
Вообще IMHO NULL имеет смысл использовать довольно редко, особенно учитывая что стандартные визуальные контролы не дают пользователю возможности вводить NULL или проверять значение на NULL

Да, это конечно основная причина дла типа визуал программеров на [censored] с кривыми [censored] растущими из [censored]

12. Roman S , 21.03.2002 14:39
QZ
Пока народ будет цеплять формы для ввода/обновления напрямую к записям БД — мы без работы не останемся

А вот по поводу «визуал программеров на [censored]» — недостойно это нашего модератора, ибо [censored] при грамотном использовании достаточно [censored] штучка, т.к. освобождает от рутинной и [censored] работы.

13. KAE , 21.03.2002 14:41
Константин_С
«To minimize maintenance and possible effects on existing queries or reports, it is recommended that you minimize the use of null values. «
Мда.
Боятся кривых рук разработчиков ?
Вообще интересно, как это «possible effects on existing queries», то есть запросы уже есть, а базы еще нет ?
14. Roman S , 21.03.2002 14:42
Если к делу — то «неопределено» — это и есть NULL, рекомендацию же к минимизированию использования NULL — лучше понимайте так, чтоб в Вашей БД конструктивно был минимум неопределённых значений.
15. Dmitri2 , 21.03.2002 14:59
Kid_Deceiver

цитата (QZ): типа визуал программеру на [censored] с кривыми [censored] растущими из [censored]

понятно что он правильно возвращает, пользователю почему-то непонятно

Roman S
Мы — это кто?

QZ
Без комментариев .

16. Roman S , 21.03.2002 15:12
Dmitri2
Мы — это программисты

P.S. А форму к БД цеплять действительно никогда не нужно! Транзакция должна начинаться _после_ заполнения формы!

17. ANDYRE , 21.03.2002 15:24
Для numeric NULL скорее будет неудобен,

для строк скорее по барабану,

для datetime весьма полезен, если datetime в конкр. записи не задано (ну не пихать же туда 1/1/1900) ,

для blob/binary очень кстати,

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

Короче, действуй из здравого смысле

18. Kid_Deceiver , 21.03.2002 15:44
Dmitri2
пользователю почему-то непонятно
Что пользователь текст SQL запроса что ли видит.
А если пользователя не удовлетворяют _результаты_, значит запрос составлен _криво_, и составившим его программисту(ам) нужно делать выводы.

ANDYRE
Ваши утверждения по меньшей мере безосновательны.

19. Константин_С , 21.03.2002 15:46
Хорошо. Вот, предположим, есть два варианта для хранения неопределенных значений:

1. Пишем в поле NULL.
2. Договариваемся (сами с собой на уровне приложения) использовать в качестве «нет значения» какое-то определенное значение (к примеру, нуль для типа данных int).

Понятно, что в обоих случаях можно сделать SELECT, отфильтровывающий все строки, для которых «нет значения» или, наоборот, есть значение. А есть ли разница в том, как сам SQL-сервер обработает эти запросы в смысле производительности и затрат? Включает ли он для NULL какие-то отличающиеся механизмы или алгоритмы? Или для него NULL — это просто одно значение из множества, стоящее в одном ряду с остальными?

20. Kid_Deceiver , 21.03.2002 15:51
Константин_С
есть ли разница в том, как сам SQL-сервер обработает эти запросы
Разница в первую очередь — в логике.
Например понятие NULL существенно при построении JOINS. А если ты начнешь это моделировать при помощи «каких-то определенных значений » то:
1. В 1% случаев ты «руками» сделаешь то, что SQL серверу положено делать самому и гораздо быстрее и эффективнее, чем тебе вручную.
2. В 99% случаев ты наделаешь ошибок, или база получится медленная ( немасштабируемая, с потенциальными нарушениями целостности и т.п. — на выбор)
21. ZanZag , 21.03.2002 15:57
ANDYRE абсолютно верно! полностью согласен. очень яркий пример с датами. если для числа чеще всего null=0 на логическом уровне, то дата иногда просто нужна пустая. это корректнее.

и еще, что-то я забыл, а такая глобальная штука как «ститат все null нулями» уже не во всех БД поддерживаеться?

22. Kid_Deceiver , 21.03.2002 15:57
сами с собой на уровне приложения
А если какое-то другое приложение, не твое. захочет поработать с это базой. Ему что — вешаться или все порушить.

NULL (маленькая частность) как и другие SQL фичи работают на самое главное — на отделение данных от приложений их обрабатывающих.
Именно поэтому NULL, являющийся часью SQL стандарта есть благо, а «какие-то предопределенные значения на уровне приложений» — есть зло.

Добавление от 21-03-2002 16:00:

ZanZag
Специально для знатоков. NULL — implementation dependent. Причем тут нули. Это логическое понятие!
Если это где-то криво реализовано, SQL стандарт тут ни при чем.

цитата: ZanZag:
и еще, что-то я забыл, а такая глобальная штука как «ститат все null нулями» уже не во всех БД поддерживаеться?

А разве такое во всех БД было?

23. iamphet , 21.03.2002 16:02
24. Kid_Deceiver , 21.03.2002 16:06
iamphet
Такого не было НИКОГДА Модет он с языком С путает?
25. Roman S , 21.03.2002 16:11
ANDYRE
> Для numeric NULL скорее будет неудобен
Кто сказал?
tg(90)=NULL

Слухайте Kid_Deceiver-а, он всё верно сказал.
ZanZag
> а такая глобальная штука как «ститат все null нулями»

Стандарт SQL для таких дел имеет функцию COALESCE, она же VALUE, она же IFNULL.

SELECT COALESCE(MAX(something), 26. ZanZag , 21.03.2002 16:59

Kid_Deceiver
Специально для знатоков
тихо тихо. без наездов, ок? я поторопился и не совсем точно выразиллся. а нули я ни с чем не путал.
есть такая ерунда, считать blank as zero . но это из другой оперы. лажачка. что-то я того последнее время, фигню порю. вредно долго фокс админить причем чужеписный.

iamphet не небыло. извини что напугал

27. KAE , 21.03.2002 17:45
ZanZag
абсолютно верно! полностью согласен. очень яркий пример с датами. если для числа чеще всего null=0 на логическом уровне, то дата иногда просто нужна пустая. это корректнее.
Вы так редко встречаетесь с количественными характеристиками, для которых 0 является допустимым значением ?

Лично я практически на каждом шагу.

28. Константин_С , 21.03.2002 17:51
Вобщем, как я понял, по поводу использования NULL не будет ошибкой сказать:
«В меру и, главное, с умом»?
29. ZanZag , 21.03.2002 18:08
KAE . наоборот. я имел ввиду, что для количества (ну товара например) 0 и null суть есть его отсутствие. т.е. =
30. ANDYRE , 21.03.2002 20:12
2 ZanZag

кстати, результат следующего (TSQL) примера

выдаст тебе NULL
Не надо объяснять какое веселье вызовет этот результат для того-же количества товара
Так что поосторожнее с NULL

31. Roman S , 21.03.2002 20:25
ANDYRE
Отличный пример допилнительной подстраховки.
Косяк не пройдёт. Или думаете, что добавив десяток к +- бесконечности получим что-то определённое?

Или думаете, что результат никого не насторожит?

Другое дело, что «специалиста», который хоть в какой-то мыслью допускает, что в БД возможна проводка с НЕОПРЕДЕЛЁННЫМ кол-вом товара, нужно подвесить за то место, которое ему всегда мешает.

32. Daleko otsyuda , 21.03.2002 22:33
Po povodu stremleniya umen’shit’ veroyatnosti poyavleniya / raboti s NULL-om (tak kak eto napisano v MSDN) IMHO eto bull sh*t. Nu nikak bez etogo nel’zya. Gde-to v applikuhe polya mozhno pustimi ostavlyat’ (da.da. estestvenno, chto neliniviy programmist napishet kuchu defaultov, constraintov i t.d) , gde-to eshe null vilezaet.

No horoshiy ton napisaniya SQL coda eto ispol’zovaniye ISNULL funczii KAK MOZHNO CHASHE
Tak chto variantov tipa
SET @a = @a + NULL
ne dolzhno bit’

33. Константин_С , 22.03.2002 10:11
iamphet
Этот спор ведется уже не один десяток лет Одни говорят, что привнесение трехзначной логики было огромным прорывом, другие — что величайшим промахом

Где можно почитать на эту тему? Если есть ссылки, киньте, please.

34. ZanZag , 22.03.2002 11:27
ANDYRE :wow: сегодня буду посмотреть на IB! блин, я представляю сколько времени яб убил на отладку еслиб такое случилось.. ну попалось поле с null и за опред. период запрос что бы выдал? нда. век живи и все равно дурнем помрешь
35. ANDYRE , 22.03.2002 11:33
Опять же кстати, функции агрегации, по кр мере в MSSQL, NULL великодушно прощают, как IB — не помню .
36. ZanZag , 22.03.2002 11:34
Daleko otsyuda
Tak chto variantov tipa
SET @a = @a + NULL

ну да. а если надо просто суммировать? поля суммировать. типа @a = field1 + field2 и один из field в конкретной записи null имеет. тут то и того. а почему быть не должно? тут дефаулт = 0 просто обязателен.

Добавление от 22-03-2002 11:38:

ANDYRE
функции агрегации, по кр мере в MSSQL, NULL великодушно прощают

одно могу сказать точно, никогда в серьез над этой темой не задумывался. сейчас базку проектнуть надо (перенести с десктопа на сервер) уделю null’ам особое внимание!

37. Daleko otsyuda , 22.03.2002 16:02
ZanZag
Nu ya i govoryu

ISNULL ispol’zovat’ chashe nado

SET @aa = ISNULL(@c, 0) + ISNULL(@d, 0)

38. Архивариусъ , 24.03.2002 10:56
Константин_С
Какие есть точки зрения, какие «за» и «против»?

Я стараюсь избегать NULL.
Причина простая. Внутренние объединения пропускают такие строки.
Внешние не пропускают, но о недостатках внешних объединений можно поговорить в другой теме. Хотя там и говорить особо нечего.

Т.е. я использую вариант 2.
Например в справочной таблице делаю значение типа:
-1 | Неопределено

А в подчиненной, на связанное поле DEFAULT -1

Вощем вот мое ИМХО — следует избегать NULL-значений в полях которые используются для связей между сущностями. В остальных случаях вполне возможно.

39. KAE , 24.03.2002 11:50
Архивариусъ
Вощем вот мое ИМХО — следует избегать NULL-значений в полях которые используются для связей между сущностями. В остальных случаях вполне возможно.
Вообще-то, поля, используемые для связи должны являться первичным ключом.
Первичный ключ не может быть NULLом (это в любой БД если не ошибаюсь)
При чем здесь использование/неиспользование NULL не понимаю.

40. Roman S , 24.03.2002 11:57
KAE
NULL — только там, где _в принципе_ возможна неопределённость значений.
Главные же ключи — значения определённые по сути своей.
41. KAE , 24.03.2002 11:59
Roman S
Я именно это и сказал.
42. Архивариусъ , 24.03.2002 21:48
KAE
Вообще-то, поля, используемые для связи должны являться первичным ключом.
А вот ерунду говорить совсем не обязательно.
Слово должны тут совсем неуместно.

Слово связь подразумевает, как минимум, две стороны
Со стороны справочника это, как правило, первичный.
С подчиненной стороны это, как правило, FK.
Но и это совсем не обязательно.
Ссылочную целостность можно поддерживать и на триггерах, например.

При чем здесь использование/неиспользование NULL не понимаю.
При том, что нет запрета использовать NULL для FK.
Теперь понимаешь?

43. KAE , 25.03.2002 16:44
Архивариусъ
Объясните мне пожалуйста одну вещь.
Если поле является первичным ключем хотя бы с одной из сторон, то может ли оно содержать NULL (не надо торопиться с ответом )

Второе, каким образом вы собираетесь обеспечивать уникальность связи, если не будете пользоваться первичным ключом ?

Добавление от 25-03-2002 16:46:

При том, что нет запрета использовать NULL для FK.
Нету.
Согласен.
А почему во внутреннее объединение должны попадать строки у которых связь не установлена ?
То есть в чем конкретно неудобство NULL ?
Не понимаю.

44. Serg Inc. , 25.03.2002 17:25
KAE

Как я понимаю, Архивариусъ имеет ввиду ситуацию, когда поле является необязательным для ввода и при этом ссылается на справочник. Например, в анкете можно указать наличие водительских прав. Их может не быть, а если они есть, то одной из существующих категорий, перечисленных в справочнике. Поле nullable, при этом FK. Пример, мягко говоря, не очень удачный, но придумывать другой мне некогда и лень .

45. KAE , 25.03.2002 18:18
Serg Inc.
Ну и что ?
В чем недостаток NULL в этом примере ?
46. Serg Inc. , 25.03.2002 18:28
KAE

В чем недостаток — вопрос к Архивариусъ .

цитата: А почему во внутреннее объединение должны попадать строки у которых связь не установлена ?

Я ответил на этот вопрос.

47. Архивариусъ , 25.03.2002 21:25
Если поле является первичным ключем хотя бы с одной из сторон, то может ли оно содержать NULL (не надо торопиться с ответом )
Нет. Ну и что дальше?

Второе, каким образом вы собираетесь обеспечивать уникальность связи, если не будете пользоваться первичным ключом ?
А где я говорил что не буду пользоваться первичным ключом.
И ваще, как-то тебя в сторону PK все время заносит. Вроде не про него речь. И я про него не спорю, с ним все предельно ясно.

В чем недостаток NULL в этом примере ?

Спасибо Serg Inc. за некоторую помощь в объяснениях.
Так вот, рассмотрим в чем недостаток на его примере.
Допустим, данные такие:
Иванов имеет категорию С
Петров В
Сидоров — ничего.

Начальник просит распечатать список сотрудников, и при этом если есть права, то указать какой категории.
Получится, при внутреннем объединении:
Иванов С
Петров В
и все. Сидорова не будет совсем.
Вот и недостаток. Начальник то, просил всех.

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

48. WPooh , 26.03.2002 06:19
Архивариусъ
OUTER JOIN спасет начальника, Сидоров в список все-таки попадет. Вроде в мануалах про это написано. Если вам нужен INNER JOIN или определенность значения атрибута(см. ниже), добавьте в справочник запись «нет водительского удостоверения», пронесите ссылки на эту запись и все станет шелковистым.

Мои центики в копилку. Значение некоторого атрибута, равное NULL означает, что значение этого атрибута не известно либо его нет. Есть пустые строки, есть числа вида 0, которые указывают на соответствующие величины атрибута. Например, число публикаций конкретного человека может быть 0, его любимый сорт пива «», так как он вообще не пьет пива. А вот если число его публикаций неизвестно, то это уже скорее NULL, а не 0. Некоторые еще различают понятия «неизвестно совсем» и «неизвестно пока». То есть, например, у старого работника есть пенсионый полис, но он его пока что с собой не прихватил, ну занесем в базу номер позже. А вот у молодого парнишки этого полиса нет еще (и не известно, когда будет, может и не будет совсем — за рубеж свалит через полгода). То есть, им не хватает просто NULL, им нужно еще какое-то значение, обозначающее нужное им понятие.
Возможно, примеры не совсем удачные, но, я надеюсь, мысль моя понятна. Не смешивайте значения 0 и NULL, если это возможно.
Это сугубо мое ИМХО, у вас может быть другая точка зрения.

49. Архивариусъ , 26.03.2002 13:47
WPooh
OUTER JOIN спасет начальника, Сидоров в список все-таки попадет. Вроде в мануалах про это написано.
Я оговорил, что говорю именно о внутреннем соединении.

Если вам нужен INNER JOIN или определенность значения атрибута(см. ниже), добавьте в справочник запись «нет водительского удостоверения», пронесите ссылки на эту запись и все станет шелковистым.
Я про то и толкую, видимо ты только последние месаги прочел. Выше я тоже самое говорил.

50. Coon , 26.03.2002 14:07
Архивариусъ
Нет, объясни только, зачем ограничивать себя внутренними соединениями, чем внешние ущербны? Каждое для своих задач(запросов) и существует. Сам раскладываешь грабли, сам раскидывыешь метки для их обхода.
Между нами, это элементарные вещи, описание которых есть в любом мануале по SQL. Не те у вас мануалы. Сорри за резкость. Пример с вод. правами показателен.

Добавление от 26-03-2002 14:17:

WPooh
Насчет NULL полностью согласен — иногда и его не хватает (хотя это все же редкий случай). Так что смысла отказываться от него не вижу, в упор не вижу. В УПОР.

Архивариусъ
А вот, кстати, при таком подходе как извращаться, если надо чтобы неопределенные значения в выборку НЕ попали? Праильно, писать WHERE [foo] <> [неопределенное значение предопределенное заранее] (sic!) наложенное на INNER JOIN. В то время как NULLABLE FOREIGN KEY с помощью внутренних и внешних объединений расставит все точки над ё. Это к вопросу о производительности тоже, каковая на объединениях прежде всего и страдает.

51. carper , 26.03.2002 14:40
WPooh
Все абсолютно верно!
Кстати, когда не хватает NULL, то используются системы нечеткой логики.
Вполне имеют право на существование весовые к-ты «неизвестности» и т.п.

Плохо тут только то, что существующие СУБД не имеют внутренних средств работы с подобными системами.

А болезненная путанность в голове между NULL и 0 IMHO у многих проистекает, как тут уже говорили, от познаний в С и С++. Многия знания — многия печали.

P.S. Кстати, ранее у компьютеров еще существовали такие понятия как плюс и минус бесконечность. Очень даже удобно было их иногда использовать.

52. Coon , 26.03.2002 14:45
carper

P.S. Кстати, ранее у компьютеров еще существовали такие понятия как плюс и минус бесконечность. Очень даже удобно было их иногда использовать.

Да ты что? А поподробнее, интересно! В каких компах, каким образом, а главное — нафиг? посл. 3 слова — шутка

53. carper , 26.03.2002 17:53
Coon
Ой!
Стояла такая бааальшая байда, кажется IBM 370 (точнее ее копия в виде соотв. серии EC) там это, кажись, и было. Подробности, равно и как пользовать Fortran IV and Assembler в EC VM я уже давно не помню.

Мои «кажись» относятся не к существовании подобной машины, а к ее конкретной марке, бо процессорное время стрелялось где только можно, начиная от собственного институтского ВЦ и кончая Дубной (на чем только не работали — и на НАИРИ и на VAX и на Atari и . даже на спец. компьютере моделирующем нейронные сети (это, впрочем, только на выставке, кажется, было) — отсюда полная мешанина в голове осталась) и т.п.

54. Архивариусъ , 26.03.2002 21:11
Нет, объясни только . чем внешние ущербны?
Тем, что они не соответствуют реляционной модели.
Объединение таблиц соответствует произведению множеств.
А в произведение неопределенные строки не войдут.
И хочу напомнить, что в стандарте SQL1 внешнего объединения совсем небыло.

В реальности внешние объединения могут облегчить некоторые вещи, например вышеуказанный пример, но «этих преимуществ удалось добиться за счет значительного усложнения прежде одной из самых простых частей языка SQL».
Грофф. «SQL. Полное руководство». Глава «Объединения и стандарт SQL2».

55. Coon , 27.03.2002 07:16
Архивариусъ
А SQL зачем совершенствовали, принимали новые стандарты, если все так круто было в первом варианте? Тупицы, однозначно! SQL1 и Алгол рулят!
Чего такого сложного увидел Грофф во внешних объединениях, до этого мне уж не допереть — видать, старею.

Добавление от 27-03-2002 07:17:

Флейм попер, ща придет QZ и всех построит

56. rGlory , 27.03.2002 08:36
carper
Стояла такая бааальшая байда, кажется IBM 370 (точнее ее копия в виде соотв. серии EC) там это, кажись, и было.
754-1985 IEEE
Floating Point Numbers
И там не только плюс и минус бесконечность, также +0 и -0 и также NaN (не число) двух видов. И операции над ними:
n / ±Infinity 0
±Infinity x ±Infinity ±Infinity
±nonzero / 0 ±Infinity
Infinity + Infinity Infinity
±0 / ±0 NaN
Infinity — Infinity NaN
±Infinity / ±Infinity NaN
±Infinity x 0 NaN

Так что большинство процессоров до сих пор с ними работает при операциях с плавающей точкой.

57. carper , 27.03.2002 10:33
rGlory
«754-1985 IEEE
Floating Point Numbers»
Спасибо!

«Так что большинство процессоров до сих пор с ними работает при операциях с плавающей точкой.»
Не совсем понял, это к персоналкам тоже относится? Если да, то что-то я не помню таких ассемблерных кодов.
Или это только внутренние представления данных без доступа извне?

58. ZanZag , 27.03.2002 11:03
ну все орлы, ща вам QZ покажет +- бесконечность с плавающей точкой

А про даты? про даты забыли? Есть хоть один реальный пример, где мне вместо null нужна константа неопределенности (типа 01.01.0001 чтоль? или 11.11.1111 )? помойму от такого только гемора больше. особенно в логике. если это например дата продажи. это еще и клиент должен пусто показывать вместо такой константы. так что с датами?

59. Coon , 27.03.2002 11:34
ZanZag
Что с датами, что с числами — когда определен конечный ряд значений, нет никакой гарантии, что он не пригодится в будущем ВЕСЬ. Поэтомцу и нужен null. Единственный ИМХО тип данных, где без null’а как то можно прожить — это строка.
60. ZanZag , 27.03.2002 11:44
Coon да я конкретный пример хотел услышать, где в дате null плохо и почему. чтоб прочувствовать и уж дальше решать что куда и как.
61. Архивариусъ , 27.03.2002 12:11
А SQL зачем совершенствовали, принимали новые стандарты, если все так круто было в первом варианте? Тупицы, однозначно!
Это скорее не совершенствование, а уступка. Есть спрос на внешние объединения вот отдел менеджмента и предлагает его ввести в конкретную СУБД, с целью обойти по возможностям конкурентов. Ну а остальным приходится подтягиваться, а потом уже это становится настолько распространенным, что и в стандарт их заносят. Причем заносят с целью установить однообразие нотации.

до этого мне уж не допереть
Ну у тебя еще все впереди. Побольше книжек по менеджменту читай, не всё технари решают.

62. Coon , 27.03.2002 12:11
ZanZag
Ну для дат простейший пример — диапазон актуальности чего-либо с заранее неизвестной датой окончания действия. Например, срок действия какого-либо договора — дата начала известна, дата конца — когда договор порвут. Здесь выгоднее использовать +бесконечность, но такого нет, поэтому выбор стоит между null и максимальной датой диапазона. Лично мне второй вариант приятнее — более прозрачными получаются запросы. А null он и есть null — неопределенность.

Добавление от 27-03-2002 12:14:

Архивариусъ
ну у тебя еще все впереди. Побольше книжек по менеджменту читай.
Нет уж, спасибо — своих хватает, по программированию. А если ты сам не заседал на собраниях комитета по стандартизации, не забывай добавлять ИМХО.

63. Архивариусъ , 27.03.2002 12:20
своих хватает, по программированию
Видимо не хватает.
А если ты сам не заседал на собраниях комитета по стандартизации, не забывай добавлять ИМХО
Не обязательно заседать, можно прочитать, о истории развития стандарта.
Так что это не мое ИМХО, а объективная реальность.
64. carper , 27.03.2002 13:26
Coon
«Здесь выгоднее использовать +бесконечность, но такого нет, поэтому выбор стоит между null и максимальной датой диапазона.»
Не совсем так, Вы же сами правильно отметили, что NULL=неопределенность, а совсем не бесконечность. Грубо говоря, бесконечность просто одно из бесчисленных возможных значений для NULL.
Поскольку в современных СУБД отсутствуют понятия для плюс или минус бесконечности, то приходится задавать их условные эквиваленты, но NULL здесь самый неудачный кандидат.

Применительно к датам в договорах, я бы использовал максимально большую дату для договоров срок окончания действия которых «не установлен». Здесь есть тонкость — срок -то НЕ НЕИЗВЕСТЕН. наоборот очень хорошо известно, что договор условно бессрочен, т.е. срок действия равен бесконечности — вполне определенному математическому понятию.
NULL же было бы уместно использовать в тех случаях, когда срок окончания договора мне именно НЕИЗВЕСТЕН. Может это договор еще в силу и не вступал и срок будет уточнен позднее, может я этот срок просто пока не знаю и надо спросить менеджера, может этот договор закончится через 3 дня, может он бессрочный. Я НЕ ЗНАЮ!

То же относится и к любым другим понятиям. Если в моей базе вместо отчества стоит прочерк или пустая строка, то это значит, что я ЗНАЮ, что этот человек отчества не имеет (например, он иностранец), если там стоит NULL, то это значит только то, что я понятия не имею какая у него фамилия и есть ли она вообще.

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

65. ZanZag , 27.03.2002 17:16
carper это очень условно. очень! све зависит от внутренних бизнесправил в фирме. комуто удобно смотреть на пустое значение и понимать что договор бессрочен (а не неизвестно когда он кончаеться). а кому-то больше бодойдет дата типа 01.01.3000. При этом другой человек начнет от такого в конвульсиях биться.

но с этим понятно. вопрос спорный, тут надо думать как лучше.
а вот «дата продажи». пока не продано лучше null мне кажеться, потому как другое значение именно говорит о том что проданно. или что, лишнее поле воротить со значением продано/непродано?

66. Coon , 28.03.2002 07:05
carper
Дык я собственно то же самое и сказал, только не жевал

ZanZag
А вот с Вами позвольте не согласиться. 01.01.3000 — всего лишь условность, принятая разработчиком базы/программистом для ВНУТРЕННЕГО ПОЛЬЗОВАНИЯ. К конечному пользователю вместо 01.01.3000 должна прийти фраза «договор бессрочен». Так что при проектировании БД не стоит заострять внимание на том, «комуто удобно смотреть на пустое значение и понимать что договор бессрочен (а не неизвестно когда он кончаеться). а кому-то больше бодойдет дата типа 01.01.3000» — все равно ВСЕГДА найдется человек, которому что-то будет неудобно, а наше дело — уже потом подстраиваться, но не перекраивая БД.

Добавление от 28-03-2002 07:08:

ZanZag
Кстати, о дате продажи. Сама постановка вопроса свидетельствует о том, что БД скорее всего спроектирована неверно. Не нужна тут никакая интерпретация — нет факта продажи — нет строки в соответствующей таблице. И всё. Это, конечно, ИМХО, может постановка задачи такая невероятная, что иначе никак, и все же.

67. ZanZag , 31.03.2002 05:08
Coon
Ну позвольте и с вами не согласиться.
Про дату продажи. нет записи в определенной таблице. ага это да, это хорошо так козырнуть. мол где полная нормализация БД. Так вот нормализация должна быть разумной, спорить будем? не в одной книжке сие сказано, да и практика работы это подтверждает, а то можно вообще из плевой задачи непроворотную бд сделать.

а вот про договор, так опять же. да я разве спорю что вместо 01.01.3000 должна прийти фраза «договор бессрочен» и
ВСЕГДА найдется человек, которому что-то будет неудобно
совершенно верно. вот только речь то шла, чем же так лучше 01.01.3000 чем NULL если конечный юзер этого напрямую касаться не будет.

68. Vladimir Rybinkin , 31.03.2002 11:52
Хм. Какая тема-то, оказывается, интересная. А я все не заходил . Дам и свою версию.

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

Теперь — что оно означает, сие логическое понятие? Отсутствие значения? А почему? Потому что забыли написать? Или значение не существенно в любом случае? У меня использовались оба эти понятия, и еще какое-то третье, не помню. Здесь еще вон про бесконечности говорят. Так что маловато одного NULL на тип .

Нужно-не нужно: по-моему, ответ очевиден. NULL позволяет приложению что-то «соображать», что-то автоматизировать (например, требовать устранения всех NULLов от операторов ). Так что смысла отказываться от него не вижу, в упор не вижу. В УПОР.

цитата: «специалиста», который хоть в какой-то мыслью допускает, что в БД возможна проводка с НЕОПРЕДЕЛЁННЫМ кол-вом товара, нужно подвесить за то место, которое ему всегда мешает.

null или no deafault

Привет!
При создании таблиц в БД как то не задумывался над тем какое состояние по умолчанию задавать таблице.
Когда численный тип как то логически легче (можно установить 0, 1 . ), а когда text, char, varchar становится не понятно какое же состояние по умолчанию дать полю — null или no default.
Не пойму разницу м/у ними, и
null — ничто (потому что null — это не 0), и
no default — ничто.
Помогите разобраться, увидеть грань что ли

29.10.2011, 04:22

Choose Deafault Run Target
При запуске проекта всегда выскакивает вот это ,это к чему надо путь указать?

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

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

Catch nullpointerexception или if != null
Добрый день, возник вопрос, какой стиль считается хорошим, делать проверку на null в if выражении.

29.10.2011, 06:08 2
42 + NULL 42 <> NULL NULL = NULL 42 IS NULL NULL IS NULL
NULL NULL NULL 1

No default — нет конкретного значения по умолчанию. В этом случае, если поле может содержать NULL, то NULL и будет по умолчанию (т.е. нет конкретного значения). Если не может быть NULL (т.е. не может не иметь значения, т.е. всегда имеет конкретное значение), то по умолчанию уже неявно, но все равно будет «пустое» значение: для чисел — 0, для строк — пустая строка.

29.10.2011, 06:31 [ТС] 3
29.10.2011, 06:41 4

Значение «неопределенность». Почти все обычные операции с неопределенностью дадут неопределенность (сложение и сравнение в примерах выше). Как в математике: ∞+42=∞
Это даёт своего рода гарантию, что если где-то всплывет NULL, то мы это обязательно заметим, если изначально на него не рассчитывали.

Отдельный интерес вызывают логические операции:

29.10.2011, 06:41
29.10.2011, 07:21 [ТС] 5
29.10.2011, 07:36 6
29.10.2011, 15:04 [ТС] 7

Не пойму, как поле быть не определено, и иметь определенное значение одновременно. Это первое.
2. щас зашел в phpMyAdmin
Там при создании поля можно установить NULL через checkbox и поле default, в котором через можно выбрать — None, As defined, NULL, CURRENT_TIMESTAMP.
Не понимаю разницу м/у первым и вторым NULL’ами.
И третье, вот у меня таблица пользователей, там для поля login я поставил not null (через чекбокс) и none (через default’a),
А вот для поля name поставил NULL (через чекбокс), а deafult не трогал, но оно автоматически стало null’ом.

Сделал я так, потому что . считал так правильно (т.е., наугад).
Если я поменяю эти значения, то таблица все равно работает.

Как бы вы поступили при создании такой таблицы (этих 2-х полей хотя бы) и почему? из каких соображений?

Использование значения NULL в условиях поиска

Так, если требуется найти записи в таблице PC, для которых в столбце price отсутствует значение (например, при поиске ошибок ввода), можно воспользоваться следующим оператором:

Характерной ошибкой является написание предиката в виде:

Этому предикату не соответствует ни одной строки, поэтому результирующий набор записей будет пуст, даже если имеются изделия с неизвестной ценой. Это происходит потому, что сравнение с NULL -значением согласно предикату сравнения оценивается как UNKNOWN . А строка попадает в результирующий набор только в том случае, если предикат в предложении WHERE есть TRUE . Это же справедливо и для предиката в предложении HAVING .

Аналогичной, но не такой очевидной ошибкой является сравнение с NULL в предложении CASE (см. пункт 5.10). Чтобы продемонстрировать эту ошибку, рассмотрим такую задачу: «Определить год спуска на воду кораблей из таблицы Outcomes. Если последний неизвестен, указать 1900».

Поскольку год спуска на воду (launched) находится в таблице Ships, нужно выполнить левое соединение (см. пункт 5.6):

Для кораблей, отсутствующих в Ships, столбец launched будет содержать NULL -значение. Теперь попробуем заменить это значение значением 1900 с помощью оператора CASE (см. пункт 5.10):

Однако ничего не изменилось. Почему? Потому что использованный оператор CASE эквивалентен следующему:

А здесь мы получаем сравнение с NULL -значением, и в результате — UNKNOWN , что приводит к использованию ветви ELSE, и все остается, как и было. Правильным будет следующее написание:

Oracle PL/SQL •MySQL •MariaDB •SQL Server •SQLite

Базы данных

IS NULL условие

Это учебное пособие Oracle объясняет, как использовать Oracle условие IS NULL с синтаксисом и примерами.

Описание

Oracle условие IS NULL используется для проверки значения NULL. Вы можете использовать условие IS NULL или в SQL предложении или в блоке PLSQL кода.

Синтаксис

Синтаксис для условия IS NULL в Oracle/PLSQL:

Параметры или аргументы

Выражение, которое нужно проверить на содержание значения NULL.

Примечание

  • Если expression содержит значение NULL, то условие принимает значение TRUE.
  • Если expression не содержит значение NULL, то условие принимает значение FALSE.

Пример с оператором SELECT

Ниже приведен пример того, как использовать Oracle условие IS NULL в запросе SELECT:

Оболочка Bash: выясняем, имеет ли переменная значение NULL ИЛИ нет

Я новичок в скриптах bash.

Как проверить значение NULL в скриптах оболочки Linux или Unix?

Вы можете быстро проверить наличие нулевых или пустых переменных в скриптах оболочки Bash.

Вам необходимо передать параметр -z или -n в команду test или команду if или использовать условное выражение.

На этой странице показано, как узнать, имеет ли переменная оболочки bash значение NULL или нет с помощью команды test.

Чтобы узнать, является ли переменная bash нулевой:

Вернуть true, если переменная bash не установлена или имеет нулевую (пустую) строку:if [ -z «$var» ]; then echo «NULL»; else echo «Not NULL»; fi
Другой вариант, чтобы определить, установлена ли переменная bash в NULL:[ -z «$var» ] && echo «NULL»
Определите, является ли переменная bash NULL: [[ ! -z «$var» ]] && echo «Not NULL» || echo «NULL»

Давайте посмотрим синтаксиc команды test и примеры в деталях.

Синтаксис для команды if следующий:

Другой вариант, чтобы проверить, является ли переменная оболочки bash NULL или нет

Как найти значение NULL в оболочке, если есть условие в Unix

-N возвращает TRUE, если длина STRING отлична от нуля. Например:

Пример: определить, является ли переменная bash NULL

Следующий скрипт оболочки показывает различные возможности оболочки на основе bash/sh/posix:

В пункте с NULL или IS NULL

Postgres является база данных

Могу ли я использовать значение NULL для пункта IN? пример:

Я хочу, чтобы ограничить эти четыре значения.

Я попытался выше заявление, и он не работает, хорошо он выполняет, но не добавляет записи с NULL id_fields.

Я также попытался добавить условие OR, но это просто сделать запуск запроса и работать без конца в поле зрения.

in Заявление будет разобрано идентично field=val1 or field=val2 or field=val3 . Полагая нуль там будет сводиться к field=null которой не будет работать.

Я хотел бы сделать это для clairity

Ваш запрос не будет из — за приоритет операторов . AND связывается , прежде OR !
Вам нужна пара скобок, что не является предметом «ясности», но чистая логика необходимость .

Добавленные скобки предотвращают AND связывание перед тем OR . Если нет, не было никаких других WHERE условий (нет AND ) вы бы не нужны круглые скобки. Принятый ответ немного вводит в заблуждение в этом отношении.

Вопрос ответил Даниил perfctly хорошо. Я хотел бы оставить записку о NULLS. Мы должны быть осторожны об использовании NOT IN оператора , когда столбец содержит NULL значения. Вы не получите никакого вывода , если ваш столбец содержит NULL значения , и вы используете оператор NOT IN. Это как это объяснено здесь http://www.oraclebin.com/2013/01/beware-of-nulls.html , очень хорошая статья , которую я наткнулся и мысли о сравнялась.

Так что вы исключите из нуль проверки. Учитывая нулевое значение в id_field, функция COALESCE бы вместо нулевой возвращении «unik_null_value», и путем добавления «unik_null_value в IN-список, то запрос будет возвращать сообщения, где id_field является value1-3 или нулевым.

Примечание: Так как кто — то утверждал , что внешняя ссылка мертва в Sushant Butta в ответ я отправил содержание здесь в качестве отдельного ответа.

Остерегайтесь NULLS .

Сегодня я наткнулся на очень странное поведение запроса при использовании IN и NOT IN операторов. На самом деле я хотел сравнить две таблицы и выяснить , от ли значение table b существует в table a или нет , и выяснить его поведение , если столбец содержит null значение. Так что я просто создал условие , чтобы проверить это поведение.

Мы создадим таблицу table_a .

Мы создадим таблицу table_b .

Вставьте некоторые значения в table_a .

Вставьте некоторые значения в table_b .

Теперь мы выполним запрос , чтобы проверить наличие значения в table_a проверив его значение с table_b помощью IN оператора.

Выполнить ниже запрос, чтобы проверить небытие.

Выход пришел , как и ожидалось. Теперь мы вставим null значение в таблице table_b и посмотреть , как вышеупомянутые два запроса ведут себя.

Первый запрос вел себя , как ожидался , но то , что случилось со вторым запросом? Почему мы не получили какой — либо вывод, что должно произойти? Есть ли разница в запросе? Нет .

Изменение в данной таблице table_b . Мы ввели null значение в таблице. Но как же это ведет себя , как это? Давайте разделим два запроса в «AND» и «OR» оператор.

Первый запрос:

Первый запрос будет обработан внутренне что — то вроде этого. Таким образом, null не будет создавать проблемы здесь , как мои первые два операнда либо вычисляться true или false . Но мой третий операнд a = null не будет ни оценить, true ни false . Он будет вычисляться null только.

Второй запрос:

Второй запрос будет обработан , как показано ниже. Так как мы используем «AND» оператор и ничего, кроме true в любом из операндов не даст мне никаких выходных данных .

Так как же нам справиться с этим? Мы подберем все not null значения из таблицы table_b , используя NOT IN оператор.

Поэтому всегда будьте осторожны NULL значениями в столбце при использовании NOT IN оператора.

SQL — Значение NULL

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

Как проверить значения NULL?

Невозможно проверить значения NULL с операторами сравнения, такими как =, . Вместо этого нужно использовать операторы IS NULL и NOT NULL.

Синтаксис IS NULL

Синтаксис NOT NULL

Оператор IS NULL

Следующий оператор SQL использует оператор IS NULL для перечисления всех пользователей, у которых нет телефона:

Оператор IS NOT NULL

Следующий оператор SQL использует оператор IS NOT NULL для перечисления всех пользователей, у которых есть телефон:

Цукерберг рекомендует:  Android - Android - работа с камерой
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих