Двойной стандарт? (null в sql)

← →
OW © (2011-04-18 15:13) [0]

UPDATE SUBJECT SET DATE_DELETE = null where ID_SUBJECT = :ID_SUBJECT

Хоть oracle, да и любой другой съедает, и вроде правильно
но ... не верно же, а?

как-то set_null( ) надо, не знаю...

← →
Медвежонок Пятачок © (2011-04-18 15:14) [1]

зачем?

← →
OW © (2011-04-18 15:15) [2]

для идеологической правильности

← →
Медвежонок ХМЛ © (2011-04-18 15:17) [3]

правильно это когда одинаково

... set f1 = 1, f2 = null .....

← →
Kerk © (2011-04-18 15:18) [4]

Не нужно путать операции сравнения и присваивания. Это две разные операции.

← →
clickmaker © (2011-04-18 15:18) [5]

а в чем правильность?

← →
Компромисс (2011-04-18 15:20) [6]

= в set имеет семантику присваивания (как := в Delphi или = в Java), а = в where имеет семантику сравнения (=, ==).
Писать set field is null было бы странно. Хотя set field to null лично я бы воспринял нормально.

← →
Медвежонок ХМЛ © (2011-04-18 15:23) [7]

Хотя set field to null лично я бы воспринял нормально.

Зашибись.
А если поле сегодня должно принять какое-то значение, а завтра нулл, то что, текст запроса менять в зависимости от значения ?

← →
Компромисс (2011-04-18 15:29) [8]

А если поле сегодня должно принять какое-то значение, а завтра нулл, то что, текст запроса менять в зависимости от значения ?

А Вас это не удивляет в where?
ANSI SQL требует писать where field is null либо field = "Value" в зависимости от значения. Ибо where field = null не работает.

← →
Компромисс (2011-04-18 15:30) [9]

The SQL-92 standard requires that an equals (=) or not equal to (<>) comparison against a null value evaluates to FALSE.

http://msdn.microsoft.com/en-us/library/aa259229(v=sql.80).aspx

← →
DiamondShark © (2011-04-18 15:35) [10]

> Ибо where field = null не работает.

Работает.
evaluates to FALSE.

← →
Игорь Шевченко © (2011-04-18 15:35) [11]

> для идеологической правильности

тебе проще сменить идеологию

← →
DiamondShark © (2011-04-18 15:37) [12]

> OW © (18.04.11 15:15) [2]
> для идеологической правильности

А тут всё хорошо с идеологической правильностью.

Любое выражение с NULL даёт NULL.
Присваивание NULL тоже даёт NULL.

← →
Компромисс (2011-04-18 15:40) [13]

Любое выражение с NULL даёт NULL.

Не любое. field = null дает false, а не null. field is null тоже дает boolean, isNull(field, "1") тоже дает все, что угодно, но не null

← →
DiamondShark © (2011-04-18 15:43) [14]

> Компромисс (18.04.11 15:40) [13]

Убедил.
SQL идеологически непоследователен.

Как жить-то теперь?

← →
Медвежонок Пятачок © (2011-04-18 15:48) [15]

А Вас это не удивляет в where?
ANSI SQL требует писать where field is null либо field = "Value" в зависимости от значения. Ибо where field = null не работает.

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

и не хватало этих вилок еще и на ровном месте при присваивании значений.

← →
Компромисс (2011-04-18 16:04) [16]

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

Согласен. Но меня все равно в where это удивляет. Надоедает, знаете ли, писать
where (f1 = 12 or f1 is null) or (f2 = 13 or f2 is null) or (f3 = 14 or f3 is null).
Особенно если f1 - не поле, а выражение. Не зря практически все основные СУБД ввели фунцкии типа isNull

← →
Palladin © (2011-04-18 17:32) [17]

Два сравниваемых по значению поля не содержащие значений не могут быть равны. И это, с "идеологической" точки зрения, абсолютно правильно.

← →
Компромисс (2011-04-18 17:45) [18]

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

Интерпретация null может быть разной. Например, можно считать его как спец. значением, которое ничем не отличается от остальных, но просто не должно встречаться в реальных данных. В таком случае, вполне имело бы смысл where field=null

← →
Игорь Шевченко © (2011-04-18 18:06) [19]

> Интерпретация null может быть разной

а причем тут интерпретация ? Интерпретация единицы тоже может быть разной

← →
Компромисс (2011-04-18 18:12) [20]

а причем тут интерпретация ? Интерпретация единицы тоже может быть разной

Кто сказал (в каком стандарте написано), что null - именно неизвестное значение? Может, у меня поле типа boolean и null является третьим логическим значением (ни true, ни false)?

← →
Компромисс (2011-04-18 18:17) [21]

Кто сказал (в каком стандарте написано), что null - именно неизвестное значение?

Да, это в самом ANSI SQL-92 и написнао.

← →
Игорь Шевченко © (2011-04-18 18:21) [22]

NULL - это нет значения, а не неизвестное значение.

← →
Компромисс (2011-04-18 18:41) [23]

NULL - это нет значения, а не неизвестное значение.

А как записывается неизвестное значение (ошибка данных, например)?

← →
clickmaker © (2011-04-18 18:43) [24]

> ошибка данных

ошибки данных не бывает. Бывают ошибки чтения или записи

← →
Игорь Шевченко © (2011-04-18 18:45) [25]

> А как записывается неизвестное значение (ошибка данных,
> например)?

Я не знаю, что такое ошибка данных и как она относится к NULL, я знаю, что NULL это нет значения. Не неизвестное, а его нету.

← →
Компромисс (2011-04-18 18:47) [26]

ошибки данных не бывает. Бывают ошибки чтения или записи

А если я при переводе клиента на нашу систему с нормальной СУБД импортирую исторические данные, которые до этого хранились в DBF, а там в датах мусор встречается?

Пример из личного опыта, кстати.

← →
Игорь Шевченко © (2011-04-18 18:51) [27]

Компромисс (18.04.11 18:47) [26]

для мусора (обычно) заводится значение "мусор"

← →
clickmaker © (2011-04-18 18:53) [28]

> импортирую исторические данные, которые до этого хранились
> в DBF, а там в датах мусор встречается?

это будет "ошибка импорта"

если нулл определять как "неизвестное значение", то придется уточнять : неизвестное кому, когда ......
и решать что делать, если васе оно неизвестно, а пете известно.

посему это еретическое определение нула.

Петю проще убить, чтобы определение не портил

хороший пример! гут!

> Игорь Шевченко

Оффтоп. По поводу квантовой телепортации: http://www.sciencemag.org/content/332/6027/330.short .

Все-таки присваивание и сравнение это разные операции. Посему для поборников чистоты и справедливости было бы корректно их разделять. Например, присваивание это :=, а сравнение это =. И не было бы этой проблемы. Тогда вполне допустим и понятен синтаксис: UPDATE XXX SET YYY := SEX = "MALE".

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

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

Отсутствие значения в памяти сервера как раз и означает, что оно ему не известно.

Что в лоб, что по лбу.

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

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

Не совсем так, если значение поля XXX типа INTEGER неизвестно, то мы можем гарантировать, что 5 + XXX - XXX будет равно пяти. Или 0 * XXX равно нулю.

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

ну да, сравнивать "неизвестно что, с неизвестно чем" нельзя, а вот присвоить "а хрен знает шо это такое" можно!

Sha © (18.04.11 22:00) [35]

> Отсутствие значения в памяти сервера как раз и означает,
> что оно ему не известно.

Жонглировать терминами можно до бесконечности. Можно возразить, что известно, что значение отсутствует.

Речь изначально шла о том, что для того, чтобы установить отсутствие значения, нужен специальный оператор вместо равенства.

> но ... не верно же, а?
>

не верно.
но если поле nullable и параметр может быть null, каждый первый трудящийся напишет datefld = :p а не (datefld = :p) or (:p is null and datefld is null) и не забудет это порево взять в скобки, если условие не единственное.
поэтому по просьбе эксплуататоров сделали возможность писать неправильно. так в очередной раз жизнь доказала науке, что первично, а что вторично.

Двойной стандарт? (null в sql) Найти похожие ветки