Прикольно. В Постгресе "1 is 1" не работает, а "1 is not distinct from 1" работает. А в SQLite наоборот.
В любом случае 99.9% из миллионов тех, кто пишет на SQL, голосуют ногами за "=". Потому что всякое такое "is not distinct from" это долбаная экзотика, даже не имеющая единообразной поддержки со стороны основных игроков.
Ну ладно, с равенством (пардон, с нотдистинктностью) разобрались. Что будем делать с другими парами операторов сравнения, от которых нам нужна работа по закону исключённого третьего, а мы получаем в лицо закон исключённого четвёртого? Я имею в виду меньше/не меньше и больше/не больше?
Всё в порядке с хелловорлдами. Основной юзкейс лефт-джойна - хождение между табличками по внешним ключам. Если мы идём в прямом направлении, у нас nullable слева, но not null справа (потому что там это первичный ключ). А если идём в обратном направлении, первичный ключ у нас слева.
Если ради чего-то мы используем в джойне nullable и слева, и справа, то почти наверняка будем ожидать, что дублирующиеся NULLы будут вести себя так же, как дублирующиеся пятёрки. По крайней мере у меня с ходу не получается выдумать разумный пример для обратного.
Попробуйте все NULL в этом коде заменить на 5, например, и посмотрите сами.
А вот действительно, если колонки не nullable, и мы джойним по колонкам, в которых повторяются значения, кого будем ругать за то, что у нас вылезло 11 строк? Самих себя, или потребуем, чтобы операция сравнения "5 = 5" давала бы какую-нибудь хтонь, которая бы конвертировалась в булево как false?
select *
from persons
left outer join person_mnames
on person_mnames.person_id = person.id
where person_mnames.mname = :MName
or person_mnames.mname is null
and :MName is null
Очень хотелось бы посмотреть на пример запрса, в котором троичная логика оказывается полезна. Вот пример, где она мешает:
select *
from persons
where mname = :MName
or mname is null
and :MName is null
где :MName это подставляемый из переменной параметр.
Мерзкий костыль, разве нет? Конструкции, подобные этому "or ..." приходится городить постоянно. Особенно оно доставляет в сложных запросах с множеством джойнов и нетривиальными условиями. Обход этой дебильной "фичи" уже давно доведён до автоматизма, но всё равно время от времени где-нибудь да словишь западло. Это как головная боль, к которой невозможно привыкнуть.
Всё ещё надеюсь увидеть пример запроса, где троичная логика полезна, но пока что мне что-то подсказывает, что жду зря.
Реляционная алгебра тоже вполне применима к данным, лежащим в Монге или Эластике. Помню, как нарисовал ER-диаграмму монговской базы, и это оказалось вот прям очень полезно.
Да, они не SQL. Они "Not only SQL". Но они тоже RDBMS. Не надо ставить знак равенства между SQL и RDBMS.
Да, как в примере с выносом фамилии, имени и отчества в отдельные таблицы, где атрибуты будут not null, но в результатах запроса всё равно будем иметь тот самый null.
NULL друг другу не равны (not equal), но при этом они неразличимы (not distinct)
Я же говорю, единственное место в наследии нашей цивилизации, где идентичность слабее равенства. Это как если бы в JS "===" давало true, а результат "==" интерпретировался бы как false.
Далеко не всегда. Ещё Кодд писал про то, что нам нужно два отдельных NULLа - тот, который неизвестность и тот, который "атрибут неприменим". Вес услуги или нематериального товара, расход топлива в литрах для электромобиля, дата смерти живого человека. Но идея Кодда народу не зашла, и даже примерно понятно почему.
Вообще, обстоятельств, почему клеточка в таблице осталась пустой, сильно больше, чем два. Кодировать их отдельными null-like значениями (null для одного, undefined для другого, void для пятого, empty для десятого) - только всех запутать. Одного NULLа достаточно, а если действительно будет нужно уточнение, мы точно придумаем, как его записать в базу.
Монга не соответствует стандарту SQL, Эластик не соответствует, много кто ещё не соответствует. Но это не мешает людям ими с удовольствием пользоваться.
Вообще, тенденция сейчас такова, что SQL потихоньку просачивается в самые неожиданные места. Не удивлюсь, если скоро приделают запросы к DOM в браузере. Если ещё не приделали. Тащить везде за собой эту глупую концептуальную ошибку с троичной логикой... ну, не обязательно, разве нет?
Домен boolean-значений такой же, как и все другие, в том числе и "сущностные" домены. Не хуже и не лучше. И boolean-колонка это relation между доменом первичного ключа и boolean-домена. В случае отсутствия relation будет честный null.
(впрочем, это не отменяет того, что за nullable boolean колонки нужно бить по рукам)
Речь о всяких вещах типа Dbeaver?
Прикольно. В Постгресе "1 is 1" не работает, а "1 is not distinct from 1" работает. А в SQLite наоборот.
В любом случае 99.9% из миллионов тех, кто пишет на SQL, голосуют ногами за "=". Потому что всякое такое "is not distinct from" это долбаная экзотика, даже не имеющая единообразной поддержки со стороны основных игроков.
Ну ладно, с равенством (пардон, с нотдистинктностью) разобрались. Что будем делать с другими парами операторов сравнения, от которых нам нужна работа по закону исключённого третьего, а мы получаем в лицо закон исключённого четвёртого? Я имею в виду меньше/не меньше и больше/не больше?
Всё в порядке с хелловорлдами. Основной юзкейс лефт-джойна - хождение между табличками по внешним ключам. Если мы идём в прямом направлении, у нас nullable слева, но not null справа (потому что там это первичный ключ). А если идём в обратном направлении, первичный ключ у нас слева.
Если ради чего-то мы используем в джойне nullable и слева, и справа, то почти наверняка будем ожидать, что дублирующиеся NULLы будут вести себя так же, как дублирующиеся пятёрки. По крайней мере у меня с ходу не получается выдумать разумный пример для обратного.
Хахаха, когда-то и телефоны только по проводам были.
А вот действительно, если колонки не nullable, и мы джойним по колонкам, в которых повторяются значения, кого будем ругать за то, что у нас вылезло 11 строк? Самих себя, или потребуем, чтобы операция сравнения "5 = 5" давала бы какую-нибудь хтонь, которая бы конвертировалась в булево как false?
Ага, обкостылить эту дурацкую фичу специальным ифом в коде бэкенда. Хрен редьки не слаще.
Это не везде работает. В Посгресе, например, если параметр не null, не true и не false, отвалится с ошибкой.
Не надо слов. Покажите мне код.
Так лучше?
Очень хотелось бы посмотреть на пример запрса, в котором троичная логика оказывается полезна. Вот пример, где она мешает:
где
:MNameэто подставляемый из переменной параметр.Мерзкий костыль, разве нет? Конструкции, подобные этому "or ..." приходится городить постоянно. Особенно оно доставляет в сложных запросах с множеством джойнов и нетривиальными условиями. Обход этой дебильной "фичи" уже давно доведён до автоматизма, но всё равно время от времени где-нибудь да словишь западло. Это как головная боль, к которой невозможно привыкнуть.
Всё ещё надеюсь увидеть пример запроса, где троичная логика полезна, но пока что мне что-то подсказывает, что жду зря.
Зачем? Какой в этом практический смысл? Можете привести пример кода, где это полезно?
Вписывание "специальных" фейковых значений - очень плохая практика.
А можно пример запроса, в котором действительно оказывается удобно, что ((null = null) is true) даёт false?
Реляционная алгебра тоже вполне применима к данным, лежащим в Монге или Эластике. Помню, как нарисовал ER-диаграмму монговской базы, и это оказалось вот прям очень полезно.
Да, они не SQL. Они "Not only SQL". Но они тоже RDBMS. Не надо ставить знак равенства между SQL и RDBMS.
Да, как в примере с выносом фамилии, имени и отчества в отдельные таблицы, где атрибуты будут not null, но в результатах запроса всё равно будем иметь тот самый null.
Я же говорю, единственное место в наследии нашей цивилизации, где идентичность слабее равенства. Это как если бы в JS "===" давало true, а результат "==" интерпретировался бы как false.
Далеко не всегда. Ещё Кодд писал про то, что нам нужно два отдельных NULLа - тот, который неизвестность и тот, который "атрибут неприменим". Вес услуги или нематериального товара, расход топлива в литрах для электромобиля, дата смерти живого человека. Но идея Кодда народу не зашла, и даже примерно понятно почему.
Вообще, обстоятельств, почему клеточка в таблице осталась пустой, сильно больше, чем два. Кодировать их отдельными null-like значениями (null для одного, undefined для другого, void для пятого, empty для десятого) - только всех запутать. Одного NULLа достаточно, а если действительно будет нужно уточнение, мы точно придумаем, как его записать в базу.
Монга не соответствует стандарту SQL, Эластик не соответствует, много кто ещё не соответствует. Но это не мешает людям ими с удовольствием пользоваться.
Вообще, тенденция сейчас такова, что SQL потихоньку просачивается в самые неожиданные места. Не удивлюсь, если скоро приделают запросы к DOM в браузере. Если ещё не приделали. Тащить везде за собой эту глупую концептуальную ошибку с троичной логикой... ну, не обязательно, разве нет?
Домен boolean-значений такой же, как и все другие, в том числе и "сущностные" домены. Не хуже и не лучше. И boolean-колонка это relation между доменом первичного ключа и boolean-домена. В случае отсутствия relation будет честный null.
(впрочем, это не отменяет того, что за nullable boolean колонки нужно бить по рукам)
Если придерживаться догмы, то да. Но когда дело дойдёт до дела, равенство "никаких" цветов между собой будет наименее удивляющим поведением системы.