FrankieОтсутствие значения есть суть null.
Тогда пустая строка вполне укладывается в эту суть :)

FrankieКакого ещё второго null? И как это так, что в типе данных уже есть значение?
Если мне не изменяет память, стандарт определяет null как "значение, отличное от любого другого", попросту расширяет алфавит неким спецсимволом и дает ему специфическую роль.

В принципе может случиться так, что в типе данных уже есть подобный спецсимвол, значение, играющее подобную же роль. В таком случае наличие различных между собой "sql-ного null" и "внутритипового спецсимвола с тем же смыслом" создает значительные неудобства, и будет вполне логично их отождествить. Авторы стандарта не предусмотрели этого момента, это их недочет.

FrankieКонечно, реализация языка часто приписывает это значение, когда переменная определяется, но в большинстве случаев это и есть null / nil.
Хм. Поймите: sql-ный null, паскалевский nil, дельфовый null, сишный NULL - это не то чтобы все совсем одно и то же. Это разные вещи, не стоит их безоговорочно смешивать.

FrankieИнтересно как на этот счёт ведут себя другие языки...
Ява - если не изменяет память, аналогично. В сях и сипласпласах нет стандартного класса строки, зависит от реализации. Там, где используется PChar или char*, в принципе зависит от реализации, от того, как обрабатывается этот момент. Скажем, большинство функций WinAPI понимают nil как пустую строку, но есть исключения, некоторые падают.

FrankieЛовко вы, однако, приравняли "значение" и "спецсимвол"!
Хм. Если посмотрите книги по алгоритмам и более-менее формальным аспектам программирования, начиная от машины Тьюринга, обнаружите частно используемый прием: говорят об алфавите (например, возможных составляющих входных данных) и расширяют его некоторыми специально обозначенными символами, играющими роль маркеров итп. Это позволяет удобно и наглядно излагать теоретические выкладки, не перегружая их очевидными, но объемными техническими деталями. Спецсимвол здесь - именно в этом смысле, ничего особо ловкого, признаться, не вижу.

FrankieКонечно, подобная трактовка может быть реализована, но думается, что на деле нету никакого символа, а есть просто нулевой указатель (в никуда).
Нулевой указатель и указатель в никуда - разные вещи. То, что в частном случае второе реализуется первым - это именно что частный случай, полагаться на который не рекомендуется.

Далее, тот же sql-ный null определенно не является "нулевым указателем".

Наконец, различайте символ (null) и его реализацию. null, равно как и nil - это не просто значение, это ключевые слова языка (sql и pascal соответственно). Это обозначение некоего специального понятия, спецсимвол.

FrankieИнтересно какие? Вроде как при перетаскивании информации на клиент
А при чем тут вообще клиент? Клиент - это отдельная песня.

Какие - неопределенность. Скажем, представьте себе, что в том же MSSQL Вам поставлена задача: написать ХП, которая не даст вводить в базу, например, пустые пароли. Сразу встает вопрос: как именно написать условие?

password <> '' ?

password is not null ?

( password <> '' ) and ( password is not null ) ?

length ( password ) > 0 ?

any other idea?

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

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

Александр ФедоренкоСумма двух пустых строк даст пустую строку, а сумма null и пустой строки даст null, т.е неопределенное значение, что вполне естественно.
Это может быть и "естественно", хотя я с этим не соглашусь, но не удобно.

Александр ФедоренкоИменно поэтому не может в уникальный ключ входить более двух значений null
1. Кто сказал, что не могут?
2. А почему именно более двух, а не более одного или более трех?

ChAКстати, softwarer, не просветите, как поведет себя Oracle, если наложить на поле строкового типа ограничения UNIQUE, а затем добавить 2 записи со значением NULL в этом поле. Как он будет их интепретировать, как 2 NULL-а, и разрешит, или как 2 пустых строки - и не разрешит ?
Разрешит.

Александр Федоренколюбое сравнение с null дает фальш.
Это неправда, причем заведомая неправда, противоречащая стандарту.

Sgt.PepperПростите, но почему бы используя Вашу логику не пойти дальше и в интовом атрибуте не убрать различия между null и нулем? ;)
Потому что для нуля в обычном его смысле - поле вещественных чисел и все такое - не выполняется сказанное мной требование "уже есть подобный спецсимвол, значение, играющее подобную же роль". Ноль не играет подобной роли, соответственно притягивание его к null-у будет неудобным.

Александр ФедоренкоInormix интерпретирует естественно как null и естественно второе значение запрещает.
Значит, Informix, как и MSSQL, нарушает в этом месте стандарт ANSI. Спасибо, будет лишняя информация к очередному разговору с любителями действовать "строго по стандарту".

FrankieЧиатл в какой-то книге по основам программирования, что компьютерная логика на самом деле и есть трёхначная
Хм. Боюсь Вас шокировать, но никакого "на самом деле" не существует. Компьютерная логика - такая, какая заложена в железяки и софт, какую захотим, такую и сделаем. В железки заложена бинарная логика, для реляционных баз используется трехзначная (точнее - один из вариантов трехзначной логики), для конкретного приложения, если нужно, я легко могу запрограммировать хоть восьмизначную - не суть.

Frankie softwarerА при чем тут вообще клиент? Клиент - это отдельная песня.

Вы же практик? Так на практике важно, как клиент обработает поступивший от сервера NULL.
Важно, но это совершенно отдельный вопрос, не имеющий никакого отношения к обработке NULL сервером. С точки зрения клиента мне представляется наилучшим, если клиент имеет адекватный инструмент, клиентский null.

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

А обосновать можно любой из этих ответов.

ModelRПлз подробнее.
null в outer join - всего лишь дефолт, подставляемый в определенных случаях. Достаточно дополнить синтаксис выражений в селекте конструкцией default тра-ля-ля чтобы получить outer join, не испытывающий никаких проблем от отсутствия концепции null.