>Как это подходит под "специальное значение, которое используется для обозначения

отсутствия какого-либо значения данных"?!

Так и подходит: обозначает отсутствие данных в этой таблицэ. Данных там нет? Нет! Значит, оно обозначает то, что требуется.

>В чём сложность понять отличи

Я прекрасно понимаю отличие одного от другого. Более того, я там и написал про два разных варианта.

>Это не SQL NULL, в таком случае.

Это опять заявление, не основанное на каких-то аргументах.

> У Вас есть источник получше стандарта SQL в этом вопросе?

Например, Кодд. Он, собственно, очень консистентно с 1975 года (когда впервые заявил о null) пишэт про отсутствующие значения.

Вот тут у меня есть цатата. Правда, то, что он хотел в стандарт пока не пошло (он хотел два разных marks на замену неоднозначному null) -- но его отношэние к null показывает вполне однозначно:

E.F.Codd "The relational model for database management", Version 2., pp.172

With regard to missing information, two questions seem dominant:
1. What kind of information is missing?
2. What is the main reason for its being missing?
In the relational approach, Question 1, regarding the kind of information, can be interpreted as a question concerning structural context: is the missing information a whole row, a component atomic value (a db-value) of a row, or a combination of these atomic values? There appears to be no
need to consider the consequences of an entire relation being missing because a database necessarily models just a micro-world.

Moreover, the "main reason" in Question 2 can be interpreted to mean, "Is the information missing simply because its present value is unknown to the users, but that value is applicable and can be entered whenever it happens
to be forthcoming? Or is it missing because it represents a property that is inapplicable to the particular object represented by the row involved?"

Figure 8.1 summarizes the classification by kind (the structural context) and by reason.

In a certain row of a relation that describes the capabilities of suppliers, it may be recorded that supplier s3 is capable of supplying part p5, but the current price for this part is missing. This is an example of a missing-butapplicable value. In those rows of the EMPLOYEE relation that describe
employees who are not legally married, the name of the employee's spouse is missing. This is an example of a missing-and-inapplicable value.

Note that, although there are many other ways to classify missing information, only the missing-but-applicable and missing-and-inapplicable types appear to justify general support by the DBMS at this time. In this context, "general" means independent of the particular column and of its
domain or extended data type. Since DBMS users and even designers are not yet accustomed to using techniques of this generality for handling missing information, gradual introduction appears appropriate.

A basic principle of the relational approach to missing information is that of recording the fact that a db-value is missing by means of a mark (originally called a null or null value). There is nothing imprecise about a mark: a db-value is either present or absent in a column of a relation in the
database.

поддерживаю. Дейт и в книгах, и в лекциях говорит о том, что NULL в стандарте требует доработки. и тоже ссылается на Кодда

> Так и подходит: обозначает отсутствие данных в этой таблицэ. Что-что?! Отсутствие данных в таблице обозначается отсутствием записей в ней. ;) > Данных там нет? Нет! Значит, оно обозначает то, что требуется. SQL NULL обозначает именно и только то, что указано в его определении. То, что кто-то ошибочно использует NULL-ы с другими целями — их проблемы, извините. > Я прекрасно понимаю отличие одного от другого. Но, тем не менее, считаете, что "нам известно, что значение отсутствует (не существует)" и "значение нам неизвестно" — это эквивалентные понятия?! > Это опять заявление, не основанное на каких-то аргументах. Т.е. определение из ISO SQL так и не удалось понять? И все (вполне наглядные, на мой взгляд) примеры оказались "мимо". :( > Например, Кодд. Который не имеет отношения к обсуждаемому вопросу (да, именно так!). Мы обсуждали SQL (одной из наиболее соответствующих стандарту реализаций которого является PostgreSQL, кстати), а не реляционные СУБД. > Вот тут у меня есть цатата. Я могу поискать "цататы" из статей / отчётов, где авторам удавалось выделить до 14 (да, четырнадцати) видов NULL-подобных значений, кажется. ;) Но в SQL этого почему-то тоже нет.

Да, а потом появляются статьи вроде "ответ на критику критики критики NULL в стандарте SQL Дейтом" (название я мог переврать, но суть примерно такая). ;) Т.е. да, по поводу представления специальных значений в реляционных БД сломано много копий, но стандартизировали то, что стандартизировали.

> Но, тем не менее, считаете, что "нам известно, что значение отсутствует (не существует)" и "значение нам неизвестно" — это эквивалентные понятия?! Троичная логика: нет, да, хз. Можно ложь, истина, неопределено. Можно 0, !0, null сути не меняет.

А может, "нам известно, что Oleg Egorov не пьёт коньяка по утрам" и "нам неизвестно, сколько коньяка пьёт Oleg Egorov по утрам" — тоже эквивалентные высказывания, "сути не меняет"? ;) Я же писал не про троичную логику, а именно про NULL-ы. Кстати, были же и предложения использования в языках запросов к базам данных SQL NULL-ов и двузначной логики (я точно читал статью, где авторы утверждали, что так оно было бы даже лучше). Т.е. из наличия одного не следует наличие другого, формально.

>обозначается отсутствием записей в ней. ;) Отсутствие этих данных в таблицэ, понятно. Не прикидывайтесь, что вы не поняли, это как-то снижает уровень разговора. >SQL NULL обозначает именно и только то, что указано в его определении. Это само по себе крайне спорное заявление -- но дажэ если его принять, то ровно насчёт отсутствия данных и будет указано примерно во всех вменяемых определениях (включая то из стандарта SQL, которое Вы привели). > (не существует)" и "значение нам неизвестно" — это эквивалентные понятия?! Конечно, нет. Это разные понятия. И null можэт означать как одно так и другое (в зависимости от модэли данных и самих данных). >Мы обсуждали SQL Мы обсуждаем реляцыонную модэль данных, на которую ориентируется язык SQL. Вне реляцыонной модэли рассуждения "что обозначает констркцыя INSERT () VALUES () или "что означает такой-то результат" -- абсолютно безсмысленны. В рамках языка SQL они просто есть и выводятся по указанным правилам, и ничего в общем-то не означают. И да, когда я говорю про смысл таких вещей как значения отношэний, а тем более про смысл значения null -- я, конечно, ориентируюсь на мнение Кодда, который придумал реляцыонную модэль, Null и SQL. Тем более, что в стандарте этот важный вопрос, судя по всему, описан крайне вскользь -- так, что вы его дажэ не поняли. >авторам удавалось выделить Это в реляцыонной модэли или вообще в жывых базах? Впрочем, неважно. Кодд тожэ пишэт, что, при жэлании, делить отсутствующие значения можно и дальшэ и по другим критэриям. Это вполне очевидно, и не меняет самой возможности обоих вариантов отсутствия значения.

> Не прикидывайтесь, что вы не поняли, это как-то снижает уровень разговора. Я уже неоднократно нормально написал, что думаю по этому поводу, вот и всё. > Это само по себе крайне спорное заявление Опять-таки, обсуждались NULLs в SQL — не NULL-ы Дейта, или Кодда, или прочие алгебры и логики NULL-ов (и подобных им понятий). Так что ничего спорного в этом утверждении нет — ничего более относящегося к SQL, чем стандарт, просто нет. > И null можэт означать как одно так и другое Но в SQL принято только одно из этих значений. > Мы обсуждаем реляцыонную модэль данных, на которую ориентируется язык SQL. Я — нет (и не нужно менять тему). Я обсуждал только SQL, и на "реляцыонную модэль данных" он "ориентируется" настолько, что в стандарте ни разу не встречается слово "relational", да и определяемые там таблицы не являются отношениями и т.д. и т.п. > я, конечно, ориентируюсь на мнение Кодда, И это Ваша проблема, понимаете? Плевать хотели авторы ISO SQL на Кодда и его мнение, грубо говоря. :( > Тем более, что в стандарте этот важный вопрос, судя по всему, описан крайне вскользь -- так, что вы его дажэ не поняли. Не понял my eye. Не нужно валить с больной головы на здоровую, вот и всё. > Это в реляцыонной модэли или вообще в жывых базах? Это в реальности (в моделировании). И было это ещё до Кодда, насколько я помню.