Реляционная алгебра тоже вполне применима к данным, лежащим в Монге или Эластике. Помню, как нарисовал 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 колонки нужно бить по рукам)
Ну вот да, в Питоне None==None, и никто горя не знает. А совет использовать там "is" вместо "==" при проверке на None исключительно потому, что некоторые всратые библиотеки могут переопределять оператор равенства для своих объектов, и делать это неочевидным образом. Например, могут упороться и применить троичную логику.
Вот тут как раз интуиция всегда оказывается на стороне того, что NULL=NULL. И чтобы вспомнить, что это "на самом деле" не так, приходится делать над собой усилие. Кстати, в некоторых случаях SQL работает без глупостей. Например:
select mname, count(*)
from persons
group by mname
Кто-нибудь страдает от такого хамского попрания догмы со стороны group by? Неа, все только наслаждаются.
Хмм... если "Матрица" это пародия на философию постмодернизма, который в свою очередь есть пародия на философию, то нужно ли считать этот фильм пародией второго порядка, или можно рассчитывать на то, что минус на минус даёт плюс?
Эта статья про сервисы или микросервисы? Это ведь совсем две разные вещи. Упоминаемая для примера система обработки заказов - никакой не микросервис, а полноценный сервис, который сослепу можно посчитать монолитом. А вот паттерн "Фасад" (он же паттерн "Передаст") - типичный кейс микросервиса. Так про что статья?
Если кратко резюмировать: разрабы с хорошими хард-скиллами всё равно почти все свалили, поэтому давайте набирать чисто по софт-скиллам. Даже если они совсем не способны работу работать, с ними хотя бы будет приятно общаться.
У меня был опыт принятия человека на работу так, как описано в статье. Печальная история.
А можно пример запроса, в котором действительно оказывается удобно, что ((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 колонки нужно бить по рукам)
Если придерживаться догмы, то да. Но когда дело дойдёт до дела, равенство "никаких" цветов между собой будет наименее удивляющим поведением системы.
Ну вот да, в Питоне None==None, и никто горя не знает. А совет использовать там "is" вместо "==" при проверке на None исключительно потому, что некоторые всратые библиотеки могут переопределять оператор равенства для своих объектов, и делать это неочевидным образом. Например, могут упороться и применить троичную логику.
Вот тут как раз интуиция всегда оказывается на стороне того, что NULL=NULL. И чтобы вспомнить, что это "на самом деле" не так, приходится делать над собой усилие. Кстати, в некоторых случаях SQL работает без глупостей. Например:
Кто-нибудь страдает от такого хамского попрания догмы со стороны group by? Неа, все только наслаждаются.
Хахаха, больше безумия богу безумия
Надо сделать двухфакторную авторизацию при звонках. Типа такого:
-- Привет, дорогая, как дела?
-- Никак, пока ты не сказал 6 циферок из Authy
Не знал, что через запятую можно добавить отсебятинки. Спасибо!
Хмм... если "Матрица" это пародия на философию постмодернизма, который в свою очередь есть пародия на философию, то нужно ли считать этот фильм пародией второго порядка, или можно рассчитывать на то, что минус на минус даёт плюс?
Эээээ.... это в какой версии?
Спасибо, гляну.
Эта статья про сервисы или микросервисы? Это ведь совсем две разные вещи. Упоминаемая для примера система обработки заказов - никакой не микросервис, а полноценный сервис, который сослепу можно посчитать монолитом. А вот паттерн "Фасад" (он же паттерн "Передаст") - типичный кейс микросервиса. Так про что статья?
Статья читать от счастья плакать
Умелый болтун знает, как подрулить дискуссией так, чтобы у вас сложилась полная уверенность в его выдающемся профессионализме.
А вот симулировать профессионализм на алгоритмическом лайвкодинге никак невозможно.
Если кратко резюмировать: разрабы с хорошими хард-скиллами всё равно почти все свалили, поэтому давайте набирать чисто по софт-скиллам. Даже если они совсем не способны работу работать, с ними хотя бы будет приятно общаться.
У меня был опыт принятия человека на работу так, как описано в статье. Печальная история.