guest_20040621null в таблице означает именно отсутствие данных. Т. е., их нет. Вообще. Никаких. И совершенно непонятно, почему. А null в Вашем запросе означает отсутствие у сотрудников детей определенного возраста. Т. е. несет абсолютно определенную смысловую нагрузкуПовторю, NULL в результате запроса и таблице означает одно и тоже: ОТСУТСТВИЕ ИНФОРМАЦИИ. NULL будет присутствовать не только у сотрудников, у которых дети имеют иной возраст, но и у тех сотрудников, у которых в БД нет информации о детях. Строго говоря, NULL означает, что требуемой информации нет.
guest_20040621 SemaphoreТак NULL и означает, что информации нет, тоже самое и в таблице.Дружище, пока Вы не поймете разницу между отсутствием информации и отрицательным ответом на вопрос, нет смысла дискутировать.NULL – это не отрицательный ответ на вопрос. "Отрицательный ответ" - это Ваша интерпретация отсутствия информации, как результат исполнения запроса. Вы пытаетесь поставить знак равенства между отрицательным ответом и пустым множеством, что не есть правильно.

ChA SemaphoreПо всей видимости, для Вас авторитет тот, кто пишет толстые фолиантыА для Вас, по видимому, Вася Пупкин ? Или пишущий не менее толстые фолианты Когаловский или Ульман сотоварищи ? Будьте последовательны, отрицая авторитеты.Не надо мне приписывать то, что я не делаю. Для меня авторитетом является тот, кто понимает то, о чем говорит или пишет. Ульмана и Когаловского я бы не стал упрекать в незнании теории. ChA SemaphoreДейт допустил огромное количество ошибок, он умудряется противоречить себе, любимому, непростительно частоПозвольте посмотреть хотя бы на список Ваших работ ? Кроме того, приведите, если уж на то пошло, цитату из Date, где он заблуждается относительно NULL ? Он отрицает NULL ? Так, собственно, об этом и речь, хотя это и неверное понимание, о чем и говоритРанее я привел разделы, в которых Дейт допускает промахи и ошибки. Не поленитесь и внимательно прочитайте их еще раз. И на этом мне бы хотелось прекратить обсуждение «заслуг» Дейта в этом обсуждении (хотите открывайте отдельное обсуждение). ChADate и предлагает заменять незнание значения реальным значением, которое имеет конкретный смысл для определенного типа данных, что отличается от отсутствия значения, для которого тип, вообще говоря, неопределен в принципе и может предполагаться только из контекстаВот здесь надо остановиться. NULL – означает отсутствие значения. Теперь Вы вместе с Дейтом предлагаете заменить отсутствие значения на «присутствие» специального значения. Очевидно, что Вам придется обосновать это специальное значение для каждого случая и перед разработчиками, и перед пользователями, и перед... инструментами СУБД. То есть, Вам придется многократно повторять в проектной документации, в документации администратору БД и в метаданных, что это специальное значение на самом деле является отсутствием значения, то бишь... NULL. ChAНеизвестное значение отличается от отсутствия значения, если Вы этого не понимаете, то здесь ничем помочь не могу, значит надо больше читать и много думать.Давайте не будем строить предположения о том, кто и что понимает. Хорошо?! Так вот NULL – это отсутствие значения, а UNKNOW – это НЕИЗВЕСТНЫЙ результат операции. По крайней мере, так принято в стандарте SQL (кстати, стандарты SQL тоже не глупые люди писали, например, Джо Селко – техниеский редактор комитета хорошо известен, как крупнейший специалист в области СУБД, а его книги и публикации пользуются огромной популярностью, рекомендую почитать его «Data and Databases», к сожалению, на русском перевода этой книги нет). ChA SemaphoreОднако такое решение усложнит структуру БД и, соответственно, повысит сложность запросов к БД.Да ради Бога, когда ситуация можно разрешить с помощью использования NULL, то почему не использовать. Надо только помнить, что это не потому, что NULL - это правильно, а потому, что ни одна СУБД не поддерживает механизма неизвестных значений.Заблуждаетесь. Все нормальные СУБД поддерживают «механизм неизвестных значений», наравне с «механизмом» отсутствия значений. Поддержка «механизма неизвестных значений» сводится к проекции трехзначной логики к двузначной. Если хотя бы у одного из операндов операции отсутствует значение, то результатом операции будет значение UNKNOW, которое и будет спроецировано на двузначную логику (в соответствии с правилами установленными стандартом SQL).

mirГ-н Semaphore, я не фанат Дейта, но считаю, что пытаться вытирать о него ноги не стоит.Простите, но перечитайте мои сообщения еще раз. С мойе точки зрения, Дейт хороший популист (или популяризатор), но он плохо знает теорию. Это факт и если хотите, то можно в отдельной дискуссии обсудить теоретические изыски Дейта (но я бы рекомендовал всем желающим участвовать в этом обсуждении прочитать хотя бы то, что есть на citforum в переводе Сергея Кузнецова).
mirТут вы скорее свой "имидж" резко уронили до пустозвонства, ибо делать заявления типа вашего "походя" просто недопустимо. Именно вот так это несерьезно.Ха-ха-ха... Если бы здесь обсуждали пособия для начинающих, то я бы первый привел ссылку на Дейта, но спорить о теории и ссылаться при этом на Дейта, как на авторитет... извите, но это не ко мне.
И последнее. Мой "имидж" в глазах поклонников "научных заслуг" Дейта, меня беспокоит не так сильно, как прошлогодний снег.

guest_20040621 SemaphoreПовторю, NULL в результате запроса и таблице означает одно и тоже: ОТСУТСТВИЕ ИНФОРМАЦИИУ-у-у... дружище, у Вас не только о базах данных неправильное представление. Читайте Шеннона до полного просветленияСильная аргументация! Если оппонент начинает переходить к аргументам вроде: "сам дурак", то это не может не радовать
guest_20040621 Semaphore"Отрицательный ответ" - это Ваша интерпретация отсутствия информацииПравильно. Т. е. тот самый частный случай контекстной интерпретации null. Разница, надеюсь, понятна?Это случай Вашей интерпретации! NULL - это только отсутствие информации без какой-либо интерпретации.
guest_20040621 SemaphoreВы пытаетесь поставить знак равенства между отрицательным ответом и пустым множеством, что не есть правильноДа нет, уважаемый, Вы пытались это сделать.Ну, это откровенное передергивание. Вот цитатата из Вашего сообщения guest_20040621А null в Вашем запросе означает отсутствие у сотрудников детей определенного возраста. Т. е. несет абсолютно определенную смысловую нагрузку.Надеюсь Вас не затруднит привести цитату из моих сообщений о том, что я утверждал, что NULL равнозначен отрицательному ответу (в подверждение Ваших же слов).
guest_20040621 SemaphoreС мойе точки зрения, Дейт хороший популист (или популяризатор), но он плохо знает теорию.Плохая точка зрения. Неумная.Ранее я уже сказал, что если хотите обсуждать заслуги Дейта, то открывайте новую дискуссию.
guest_20040621 Semaphoreпрочитать хотя бы то, что есть на citforum в переводе Сергея Кузнецова).Кроме citforum могу порекомендовать забор как источник информации. Качество - сопоставимо.Без комментария...

guest_20040621 SemaphoreСильная аргументация! Если оппонент начинает переходить к аргументам вроде: "сам дурак", то это не может не радовать;) Никто за рамки дискуссии не выходит. Если Вы не имеете представления о том, что пишете, моей вины в этом нет, согласитесь. Использовать термин "информация" в данном контексте просто безграмотно.Поясните свою мысль. Слово "информация" достаточно многогранно, и его использование, как синонима слов "данные", "значения полей" и т.п., в контексте данного обсуждения мне кажется вполне уместным. Если я использовал это слово неудачно, так, что смысл предложения искажался, то подтвердите это цитатой, пожалуйста. Без такого подтверждения Ваше заявление о моей безграмотности голословно.
guest_20040621 SemaphoreНадеюсь Вас не затруднит привести цитату из моих сообщений о том, что я утверждал, что NULL равнозначен отрицательному ответу (в подверждение Ваших же слов).Да нет, конечно же. На стр. 2 обсуждения найдите Ваше сообщение с утверждением о том, что null в запросе и в таблице означают одно и то же.Посмотрел и не нашел. Тот факт, что Вы не смогли привести цитаты, подтверждающей Ваш выпад, позволяет мне назвать Вас болтуном.
guest_20040621 SemaphoreБез комментария...Да и какие могут быть комментарии? На sql.ru есть товариСЧи, которые при обсуждении проектирования баз данных приводят ГОСТы как пример обязательных нормативных документов. Ладно, я посмеюсь, но обсуждения читают самые разные люди, - чего ж ахинею плести? В Вашем лице нашелся товариСЧ, который привел citforum как источник информации. Опять же я посмеюсь, но вполне могут найтись люди, которые примут это за чистую монету.
Ваша ссылка на citforum говорит гораздо больше о Вашем уровне профессиональной подготовки, чем Вы можете продемонстрировать здесь, в этом топике.Отказ в комметировании Вашего предыдущего выпада был связан с двумя причинами. Первая состоит в том, что Вы вырвали слово из контекста. Я не рекомендовал читать на citforum все подряд. Вот, что я сказал Semaphoreможно в отдельной дискуссии обсудить теоретические изыски Дейта (но я бы рекомендовал всем желающим участвовать в этом обсуждении прочитать хотя бы то, что есть на citforum в переводе Сергея Кузнецова)То есть, я говорил про работы Дейта, которые есть на citforum.
Вторая причина, отказа комментировать состоит в том, что если у Вас есть сомнения в квалификации Сергея Кузнецова, как специалиста в области баз данных, или Вы считаете его переводы неточными, то... Хотя, я понимаю, что подвердить или опровергнуть эти положения Вы тоже будете не в состоянии.

guest_20040621 SemaphoreТот факт, что Вы не смогли привести цитаты, подтверждающей Ваш выпад, позволяет мне назвать Вас болтуном.Дружище, следите за языком.
[1225576]: ...И в моем запросе, и в таблице NULL означает только одно - отсутствие данных и никакой другой интерпретации нет!...Ха-ха-ха... Скажите, как приведенная Вами цитата связана с моим вопросом? Повторю свой вопрос: SemaphoreНадеюсь Вас не затруднит привести цитату из моих сообщений о том, что я утверждал, что NULL равнозначен отрицательному ответу (в подверждение Ваших же слов).Вы либо плохо читаете, либо просто несете ерунду.
guest_20040621 SemaphoreВторая причина, отказа комментировать состоит в том, что если у Вас есть сомнения в квалификации Сергея Кузнецова, как специалиста в области баз данных, или Вы считаете его переводы неточными, то...Я не знаком с Сергеем Кузнецовым и не могу ничего сказать о его квалификации или о качестве его переводов.Вы думаете я сомневался в том, что Вы не знаете ведущих в нашей стране специалистов в области баз данных? Нет, ничуть не сомневался
guest_20040621P.S. Нормальную тему Вы превратили в флейм. Стыдно, дружище. Если нечего сказать по существу, - лучше жевать, чем говорить.Не переваливайте с больной головы на здоровую. Это Вы раздули flame из-за того, что Вам не понравилось мое высказывание о Дейте. Но Дейту была посвящена одна фраза из моего сообщения, по сути же сообщения Вы ничего не смогли сказать, едва не заблудившись между понятиями NULL и UNKNOW. Так что flame – это Ваша заслуга... "дружище"

mir SemphoreВсе нормальные СУБД поддерживают «механизм неизвестных значений», наравне с «механизмом» отсутствия значений. Поддержка «механизма неизвестных значений» сводится к проекции трехзначной логики к двузначной. Если хотя бы у одного из операндов операции отсутствует значение, то результатом операции будет значение UNKNOWN, которое и будет спроецировано на двузначную логику (в соответствии с правилами установленными стандартом SQL).Корректная «проекция трехзначной логики к двузначной» в принципе невозможна.Другими словами, тот метод проекции, который есть в стандарте, начиная с SQL 89, является некорректным? Вероятно Вы хотели сказать, что трехзначная логика не тождественна двузначной. А «корректность» приведения определяется принятыми соглашениями (в данном случае, стандартами SQL).
mirТеоретические аспекты этой невозможности (т.наз. парадоксы 3VL) и описал Дейт.Насколько я знаю, это было сделано до Дейта.
mirМогу добавить маленький пример: в рамках нормальной 2VL поддерживается оператор IF-ELSE, который имеет две ветки. Одна из этих веток всегда выполняется. В случае же 3VL двух веток мало, надо три: по TRUE, по FALSE и по UNKNOWN. Однако такого оператора нет ни в одной СУБД.Оператора IF нет в стандарте SQL.
mirКак и операторов цикла с тремя возможностями: прервать цикл, продолжить цикл и… (И что?).Любой оператор цикла представим конструкцией IF и GOTO. Если Вы допускаете существование IF с тремя «ветками», то дайте возможность программистам самостоятельно решать, что делать в «ветке» UNKNOWN (перейти к новой итерации, прервать цикл, вызвать исключение и пр.).
mirТак что полноценная поддержка 3VL в современных СУБД весьма и весьма под вопросом.У меня иное мнение. Если комитет по стандартизации SQL (куда входят специалисты всех ведущих фирм-разработчиков СУБД) примут решение о том, что необходимо ввести в обиход UNKNOWN, то поддержка трехзначной логики будет реализована «полноценно» (правильнее было бы сказать - явно).
mirТолько молю, не надо мне про возможность проверки IS NULL и т.д., все это понятно и реализуемо. Речь о теоретическом аспекте.Теоретически нет никаких проблем в том, чтобы сделать явной трехзначную логику. Вы, наверное, знаете, что SQL нельзя назвать «полноценным» реляционным языком. Теоретически нет никаких проблем в том, чтобы создать «нормальный» реляционный язык (язык, который явно поддерживает все операции над множествами). Мало того, таких языков УЖЕ было создано несколько десятков, но пользуются SQL. Аналогично и в случае с IS NULL. Можно явно ввести третье логическое значение в SQL, но... приживется ли?
mirА если все же о практическом, то можно сказать вот что: применение классических логических конструкций 2VL в условиях 3VL есть один из дополнительных источников ошибок (например, классический программист всегда предполагает автоматическое выполнению ветки ELSE при невыполнении ветки IF).Ошибки – всегда есть следствие невнимательности или незнания правил. Если программист невнимателен или не знает правил приведения трехзначной логики к двузначной, то... ему ничем не поможешь. Это первое. Второе. Явное введение трехзначной логики будет провоцировать ошибки по... тем же самым причинам (невнимательность и незнание).

mir semaphoreДругими словами, тот метод проекции, который есть в стандарте, начиная с SQL 89, является некорректным?
Разумеется. Чистой воды некорректным. Например, согласно общеизвестным правилам 3VL, любое арифметическое или логическое выражение с одним из аргументов Unk дает Unk. То есть a+b = NULL, если a=NULL или b=NULL.
А теперь посмотрите, как реализованы агрегирующие функции в SQL. Совершенно не так. Если в суммируемом столбце есть NULL-значения, они просто игнорируются. А ведь сумма SUM по столбцу должна однозначно быть NULL, есть есть хоть один NULL. Что же тут корректного?Понятие "корректности" определяется стандартом. Давайте представим к чему приведет работа агрегатных функций по Вашим правилам. Предположим, что у нас есть таблица: Исходя из Ваших правил, результат был бы UNKNOWN. Если бы вместо NULL в поле TOTAL по умолчанию подставлялся бы ноль, то и в этом случае результат был бы иным (0.75). Поэтому комитетом по стандартизации SQL принято корректное решение о правилах вычисления агрегатных функций в операторах. И это решение вполне корректно и с точки зрения теории, так как в вычислениях принимают участия только те записи, которые имеют значения в агрегируемых полях. Записи, у которых отсутствуют значения в агрегируемых полях, не участвуют в вычислениях (не попадают в выборку).
Так в чем же некорректность?

mir авторПонятие "корректности" определяется стандартом
Вот он корень наших разногласий. Понятие "корректности" IMHO определяется в первую очередь математикой, во вторую здравым смыслом. Такие вот "стандартизаторы" в одном из штатов Америки законодательно определили значение чила "пи" равное 4 (исторический факт). Но оно корректным из-за этого не сталоВыдергивание фразы из контекста – не есть пример доблести, IMHO. В моем сообщении говорилось о корректности приведения результатов полученных при операциях выполненным в трехзначной логике к результатам двузначной логики. Заметьте, речь не идет о корректности логик, а о корректности правил приведения! В качестве аналогии: есть пространственная (трехмерная) фигура, а есть (двумерная) плоскость. И то и другое не подвергается сомнению. Но существуют различные правила приведения (проекции фигуры на плоскость). И то, по каким правилам выполняется проекция, определяется стандартом.
Мне кажется, что Вы ищите проблему там, где ее... никогда не было.
mir авторпредставим к чему приведет работа агрегатных функций по Вашим правиламСекундочку, я никаких правил не предлагал. Это не "мои" правила. Это правила трехзначной логики, описанные повсеместно. Не надо вот этого, не надо.Простите, я действительно должен был сказать: «По предлагаемым Вами правилам». Еще раз приношу свои извинения.
mir авторПоэтому комитетом по стандартизации SQL принято корректное решение о правилах вычисления агрегатных функций в операторахИтак, оно "корректное", ибо принято комитетом. Читай выше про число "пи"Прочитал, но не вижу аналогии. Повторю еще раз, что комитет не принимал стандарта о трехзначной или двузначной логике, он принял решение о том, как приводить одно к другому, поскольку не существует (и не может существовать) однозначного соответствия между этими двумя логиками.
mir авторИ это решение вполне корректно и с точки зрения теории
Абсолютно некорректно. Если я буду делать a+b по правилам 3VL (не моим!), получу NULL при a = NULL или b= NULLОшибаетесь, результатом операции будет не NULL, а UNKNOWN. И прошу Вас еще раз и более внимательно прочитать то, против чего Вы возражаете.
mirЕсли же a и b есть значения атрибута в двух строках, то функция суммирования не вернет NULL. То есть она суммирует не по правилам 2VL и не по правилам 3VL, а по правилам "комитета". Браво! Число "пи" равно-таки 4!Не делайте поспешных выводов. «Суммирования» с NULL в агрегатных функциях нет. Об этом я уже говорил. Прочитайте предыдущее сообщение, разберите (внимательно!) приведенный пример (если лень читать стандарт).

mirНапример, рассмотрим операцию удаления строк DELETE FROM TABLE WHERE CONDITION . Операция для каждой строки вычисляет CONDITION и либо удаляет строку, либо нет. Однако что делать, если CONDITION=NULL ? Если удалить строку, то мы признаем, что NULL=TRUE , если оставить, то мы признаем, что NULL=FALSE . Последний вариант и работаетСие - есть заблуждение!!!
mirно он не соответствует 3VL, ибо согласно 3VL NULL<>FALSE и NULL<> TRUE . Корректным с точки зрения 3VL мог бы быть единственный вариант — отвергнуть всю операцию DELETE FROM , поскольку она не может быть обработанаМне кажется, что Вы напрасно драматизируете ситуацию. Сравнения вида NULL=TRUE, NULL=FALSE, NULL<>TRUE, NULL<>FALSE вернут значения UNKNOWN в полном соответствии с трехзначной логикой. UNKNOWN будет преобразована к FALSE (по правилам принятым стандартом SQL). Предположим(!), что у меня в кармане лежит купюра. Вы знаете ее достоинство? Такой информации у Вас, скорее всего нет. Теперь я спрошу Вас: "Это купюра достоинством в сто рублей?".Честный человек должен сказать: "Я не знаю". Предположим, что к Вам поступило распоряжение изъять все купюры достоинством ниже 50 руб. Можете ли Вы потребовать от меня, что бы я отдал Вам купюру, если Вы попрежнему не знаете ее достоинства и даже не уверены в том, что она у меня вообще есть? Стандарт говорит, что Вы не можете предъявить мне подобных требований.
mirи требовать доопределения условия CONDITION на случай наличия NULL (что-нибудь типа a<b AND a IS NOT NULL AND b IS NOT NULL )Совершенно верно.
mir(Эй, мистер, я ничего не придумываю, никаких своих правил, нет?)Замечательно. В таком тоне Вы можете общаться со своими друзьями. Я же имею честь откланяться. Прощайте.