Двойной стандарт? (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, а там в датах мусор встречается?

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

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

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

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

← →
Anatoly Podgoretsky © (2011-04-18 19:09) [30]

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

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

Anatoly Podgoretsky © (18.04.11 19:09) [30]

"Только массовые расстрелы спасут Отечество!"

← →
MDFE © (2011-04-18 19:37) [32]

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

← →
TUser © (2011-04-18 20:24) [33]

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

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

← →
Mystic © (2011-04-18 20:56) [34]

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

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

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

← →
Sha © (2011-04-18 22:00) [35]

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

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

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

← →
Mystic © (2011-04-18 22:26) [36]

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

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

← →
картман © (2011-04-18 22:27) [37]

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

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

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

Sha © (18.04.11 22:00) [35]

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

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

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

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

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

>Mystic © (18.04.11 22:26) [36]

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

Допустим, товар поступил на склад, его тут же отпустили заказчику.
Вес товара в БД не заносили. Понятно, что после всех этих операций
вес товара на складе (5) не изменился. С другой стороны он стал
равен 5 + XXX - XXX. И почему это не должно быть равно 5 ?

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

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

[42] Медвежонок Пятачок ©

Три раза прочитал и не понял. Да и очём вообще спор не понятно - есть null, есть правила - всё известно. По ИБ или ФБ помню статью об особенностях null в них.

это было размышление на тему "серверу неизвестно"

1. имеем апдейт, в результате которого в поле ложится нулл.
2. после апдейта серверу "становится неизвестно" значение в проапдейтенном поле

на основании чего сервер "решил", что значение ему неизвестно?

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

теперь остается решить, знает ли сервер, что в поле лежит нулл, или серверу неизвестно какое значение лежит в поле.

знает ли сервер, что в поле лежит нулл, или серверу неизвестно какое значение лежит в поле.

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

"..пойду, повешусь.."

> Медвежонок Пятачок © (19.04.11 09:54) [44]

вот что-то типа этого, но немного не так

> 1. имеем апдейт, в результате которого в поле ложится нулл.
> 2. после апдейта серверу "становится неизвестно" значение
> в проапдейтенном поле

Да, на основании чего сервер "решил", что значение ему неизвестно?
очевидно, что на основании того, что "он узнал", что значением параметра при апдейте был нулл.

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

Да, конечно.

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

Хотя, все это, конечно, ерунда
так, мозги/язык/пальцы поразмять

> Хотя, все это, конечно, ерунда
> так, мозги/язык/пальцы поразмять

Касторка тоже способствует

← →
Компромисс (2011-04-19 11:41) [48]

Я вчера понял, наконец, почему так сделано. Из-за реляционных операций.

Например, чтобы
select a.*
from a, b
where a.f = b.f_a

(или select a.* from a inner join b on a.f = b.f_a)
работал правильно, то есть возвращал только те строки, для которых есть соответствующие строки в b.
Иначе всегда получали бы full join.

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

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

> Mystic © (19.04.11 12:10) [49]

Когда отсутствует значение атрибута, неприменимого к объекту, тоже не все просто.

Атрибут "расход топлива на 100 км пути" неприменим к велосипеду.

Выражение 20 * x / 100 позволяет узнать, сколько топлива должен купить владелец транспортного средства, чтобы проехать 20 км. Понятно, что в нашем случае это 0 л.

С другой стороны, выражение 10 / x позволяет узнать, какой путь может пройти транспортное средство на 10 л горючего. Понятно, что в нашем случае это значение не определено.

Видим, что обоих случаях NULL ведет себя как 0. Но тогда обратный атрибут или, скажем, атрибут "время набора скорости 100 км/час" для того же велосипеда будут вести себя как бесконечность.

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

При этом, как всегда, большинство имеет шанс оказаться в меньшинстве

> Mystic © (19.04.11 12:10) [49]
> если поле это дата последнего обращения пользователя к некоторому элементу,
> то значение NULL указывает, что обращений не было.
> Посему любое использование этого значения в выражении делает его бессмысленным :)

Не любое. Например, выражение x>d можно было бы (если бы было можно) использовать для определения факта обращения пользователя к элементу после даты d.

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

"обнулить переменную совсем"

> "обнулить переменную совсем"

"Не читал, но осуждаю!"

> Sha © (19.04.11 20:50) [51]
>Не любое. Например, выражение x>d можно было бы (если бы было
> можно) использовать для определения факта обращения пользователя
> к элементу после даты d.

Дык, все логично:
Есть Вася, Вова, Петя и Сирожа
Вася - давний клиент фирмы с неведомых пор, но на сайт фирмы не заходит, иоб решает все через финдиректора.
Вова - тоже давний клиент, на заре становления сайта залез туда, ужаснулся и решил общаться только по почте.
Петя - постоянный клиент, регулярно выносит мозг техподдержке сайт фирмы
Сирожа - новый клиент, еще не обращался за техподдержкой на сайт, но обещал

Задача: выбрать клиентов, которые обращались за техподдержкой на сайт:
1) за последний год
2) за последний месяц
3) которые давно уже не обращались за техподдержкой

Не читал, но обсуждаю! :-)

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