Понятие NULL

← →
pasha_golub © (2006-10-02 11:01) [160]

> Игорь Шевченко © (02.10.06 10:50) [157]
>

Не знаю есть ли такое в Оракле, но уверен, что есть. Пример из PostgreSQL:

Создаем Foreign Key по нескольким колонкам и указываем, допустим MATCH SIMPLE:

FOREIGN KEY ( column1 [, ... ] ) REFERENCES reftable [ ( refcolumn1 [, ... ] ) MATCH SIMPLE

В этом случае "MATCH SIMPLE allows some foreign key columns to be null while other parts of the foreign key are not null".

Однако, пустую строку сюда уже никаким образом не впихнуть.

← →
ANB © (2006-10-02 11:03) [161]

В нескольких конторах, где я работал, нуллы старательно давили (кстати, запросы писать действительно проще). Т.е. во все справочники был добавлен нулевой элемент, в нынешней - в варчары пишут chr(1) (жутко непрывично, я все время забываю об этой особенности).
Однако мой оракловый сенсей наглядно мне показал, что использовать явные нуллы намного лучше и эффективнее. А если влом писать правильные запросы - не фиг идти в программисты СУБД.

← →
ANB © (2006-10-02 11:04) [162]

> Создаем Foreign Key по нескольким колонкам

ИМХО : Ну нафиг такую практику.

← →
pasha_golub © (2006-10-02 11:05) [163]

> Однако мой оракловый сенсей наглядно мне показал, что использовать
> явные нуллы намного лучше и эффективнее. А если влом писать
> правильные запросы - не фиг идти в программисты СУБД.

Поделись. Интересно узнать.

← →
pasha_golub © (2006-10-02 11:05) [164]

> ANB © (02.10.06 11:04) [162]
>
>
>
> ИМХО : Ну нафиг такую практику.
>

Нафиг не нафиг, а факт есть.

← →
ANB © (2006-10-02 11:11) [165]

> Поделись. Интересно узнать.

Ну, в частности, особенности наллов при работе в ссылках и уникальных ключах. Я уж подробно не помню, т.к. по привычке с первой работы (на которой он меня и учил) в создаваемых базах применял методу с убийством нуллов. И вот, когда мы опять пересеклись, он объяснил мне, что на первой работе эта порочная практика исторически сложилась. И разжевал, чем она плоха. Т.к. он - гуру в оракле, я принял дальше все как аксиому :)

← →
Игорь Шевченко © (2006-10-02 11:16) [166]

pasha_golub © (02.10.06 11:01) [160]
ANB © (02.10.06 11:03) [161]

Я имел в виду не аспекты реализации, а суть задач. Так вот, по сути задач мне не приходилось сталкиваться с проблемами, которые требовали бы явного отличия NULL от пустой строки.

← →
ANB © (2006-10-02 11:18) [167]

> Так вот, по сути задач мне не приходилось сталкиваться с
> проблемами, которые требовали бы явного отличия NULL от
> пустой строки.

+1.

наверное, поэтому оракл пустую строку сам в нулл и перекидывает.

← →
kaif © (2006-10-02 11:25) [168]

2 Игорь Шевченко © (02.10.06 10:50) [157]

А позволяет ли ORACLE создать уникальный ключ на строковое поле, если оно не определено как NOT NULL?
Если нет, то как мне создать набор уникальных значений (пусть это будут "отчества"), включающих "пустой" элемент?
Или ORACLE позволяет создавать уникальные ключи на поля, допускающие NULL? Или только для строк это так? Или я должен вставлять "-" для варианта "Отчество отсутствует" ? И как тогда у меня дела будут с конкатенацией? Типа "Элвис Пресли -" ? Или типа
CASE WHEN THEN ELSE END, чтобы избежать этой проблемы?

Что здесь удобного?
Я пока не вижу ни одного дополнительного удобства, которое не создало бы новых неудобств.

Вот в IB я не вижу такого неудобства. Я могу создать справочник отчеств, содержащий пустой элемент ID,NAME (0, ""). При этом поле NAME четко NOT NULL. И имеется ключ CONSTRAINT UNIQUE(NAME). И никакого гимора. И никаких "-" при конкатенации. Какое удобство я получу, если IB вдруг взумает отождествлять NULL и пустую строку? Никакого - одну головную боль.

← →
evvcom © (2006-10-02 11:30) [169]

> [159] ANB © (02.10.06 10:59)
> А NVL в FB нету.

Ну а COALESCE-то вроде есть?

> [164] pasha_golub © (02.10.06 11:05)
> Нафиг не нафиг, а факт есть.

Искоренять такие факты надо... гы, ударом по карману. :)

> особенности наллов при работе в ссылках и уникальных ключах

ссылки и уникальные ключи строятся на индексах, а нульные значения в индекс не попадают, потому, если ссылка ни на что не указывает, то это и не проверяется. А также null-значение не мешает добавлению уникальной записи, т.к. нет еще такой записи в индексе. С chr(1) в этом случае будут большие проблемы, созданные искусственно.

← →
Игорь Шевченко © (2006-10-02 11:34) [170]

kaif © (02.10.06 11:25) [168]

Я, дорогой Ашот, работал не только с Oracle. Я (еще раз) говорю о задачах, независимо от используемой СУБД, в которых не требовалось отличать NULL от пустой строки. Представь, что есть СУБД, в которой столбец со значением NULL может входить в Primary key.

← →
evvcom © (2006-10-02 11:37) [171]

> [168] kaif © (02.10.06 11:25)
> А позволяет ли ORACLE создать уникальный ключ на строковое
> поле, если оно не определено как NOT NULL?

Т.е. допускающее NULL-значения.

> Или ORACLE позволяет создавать уникальные ключи на поля,
> допускающие NULL?

По-моему, это одно и то же. Да, допускает, легко.

> Или только для строк это так?

Для любых типов.

> Я могу создать справочник отчеств, содержащий пустой элемент
> ID,NAME (0, ""). При этом поле NAME четко NOT NULL.

Аналогично, только не будет строки (0,"") в этом справочнике. Пока экономия 1 строка.

> И имеется ключ CONSTRAINT UNIQUE(NAME). И никакого гимора.
> И никаких "-" при конкатенации.

Аналогично ключ, никакого гимора и никаких "-".

← →
Reindeer Moss Eater © (2006-10-02 11:39) [172]

А как в Вашем случае передаётся пустая строка?
В моем случае никак, так как передавать нечего.
Мне известно два варианта:
1. Передать в строке некий символ, информирующий, что это пустая строка. Чаще всего в качестве такого символа используется символ 0x00. Хотя, в принципе, ничто не мешает вместо него использовать какой-либо другой символ или даже их комбинацию. Но, согласитесь, пустая строка, содержащая символ (хотя бы один) уже не является пустой строкой.
2. Передать дополнительную информацию, сообщающую, что в строке нет символов. Чаще всего в качестве такой информации используется длина передаваемой строки, хотя можно использовать, например, некий флаг, сообщающий, что строка пустая. В данном варианте физическая реализация передаёт вообще не строку, а информацию о ней.

Оба случая передают не пустую строку, а левую информацию о том, что кто-то хотел передать пустую строку.
Переданная инфа не обладает свойствами пустой строки.
Длина её не равна 0, сумма длин не равна нулю. Конкатенация с другими строками не будет равна самим строкам и т.д.

Вывод - это не способ, а фигня.

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

Соглашение для строковых типов уже уже есть - это поток байтов (юникод для простоты не рассматриваем)

Так почему если для передачи пустых строк используется дополнительная информация, то таким же способом нельзя передать NULL?
так почему же для передачи пустой строки (такого же обычного и равноправного значения как и любое другое значение строки) вдруг не с того ни с сего потребовалось доп информация?

Не потому ли что пустая строка - это особое значение строкового типа, эквивалентное нулу?

← →
evvcom © (2006-10-02 11:42) [173]

> [171] evvcom © (02.10.06 11:37)

Гы, "отправить" нажал... :)
Только в подчиненной таблице поле со ссылкой на справочник тоже будет допускать null-значения. Экономия:
1. в виде одного значения number на каждую null-строку
2. в виде отсутствия проверки на наличие "нулевой" строки в справочнике.
Ну и в sql вместо допустимого inner join надо будет использовать outer join

← →
pasha_golub © (2006-10-02 11:42) [174]

> evvcom © (02.10.06 11:30) [169]

> Искоренять такие факты надо... гы, ударом по карману. :)

Если звезды зажигаются, то значит это кому-нибудь нужно (с) не мое

← →
Reindeer Moss Eater © (2006-10-02 11:44) [175]

> Я могу создать справочник отчеств, содержащий пустой элемент
> ID,NAME (0, ""). При этом поле NAME четко NOT NULL.

Зачем в справочнике пустое отчество?
В таблице персонала создается внешний ключ на справочник.
Сам справочник имеет уникальный констрейнт на поле отчества.
Пустое значение отчества в справочнике нафиг не нужно (при создании записи в таблице открывать запрос к справочнику только для того, чтобы комбобоксом вставить в поле нулл или пустую строку?)

А вот поле внешнего ключа может содержать либо валидный ключ либо нулл.

Все логично и просто.

← →
kaif © (2006-10-02 11:49) [176]

2 Игорь Шевченко © (02.10.06 11:34) [170]
Я прекрасно понимаю, Игорь, что ты говоришь.
Но я всего лишь наставаю на том, что NULL теоретически не есть "одно из возможных значений", а есть значение, свидетельствующее о том, что "значение неизвестно". Или же нам придется пользоваться математикой вида (NULL=NULL) ==TRUE и (NULL<>NULL) ==FALSE. То есть отождествить NULL и пустое значение.

Скажу тебе по секрету, я тоже ни разу не сталкивался с задачами, где нельзя было бы все NULL в числовых полях перестать отличать от нуля. Но почему-то я не стал сторонником отказа от понятия NULL. Наоборот, я стал сторонником максимальных NOT NULL ужесточений на числовые поля.

Идея NULL заставляет нас задумываться в процессе нормализации.
Отказ от NULL нас расслабляет в этом смысле.
Если поддерживать все то, что расслабляет, то отождествление NULL с пустыми строками - и есть генеральный путь.

Предлагаю отождествлять NULL и 0 в числовых полях тоже. Если кому надо - пусть флаги лепит.
Оставим NULL только для дат.
Хотя нет.
Для дат удобнее придумать что-то вообще иное.
Давайте для удобства в ANSI SQL введем две даты: "очень давно" (ONCE_UPON_A_TIME) и "когда-нибудь в будущем" (END_OF_THE_WORLD). Знаете, насколько удобнее станет программировать!

← →
evvcom © (2006-10-02 11:49) [177]

> [174] pasha_golub © (02.10.06 11:42)

Это не звезды, это туманности. :)

← →
Игорь Шевченко © (2006-10-02 11:53) [178]

kaif © (02.10.06 11:49) [176]

> Идея NULL заставляет нас задумываться в процессе нормализации.
>
> Отказ от NULL нас расслабляет в этом смысле.
> Если поддерживать все то, что расслабляет, то отождествление
> NULL с пустыми строками - и есть генеральный путь.
>
> Предлагаю отождествлять NULL и 0 в числовых полях тоже.
> Если кому надо - пусть флаги лепит.

Ты бы привел пример о том, как заставляет задумываться или расслабляет, разговор бы предметнее был.

← →
kaif © (2006-10-02 11:57) [179]

Неужели гуру SQL или их ученики не видят разницы между "Отчество не неизвестно" и "Отчества не существует"?

← →
Reindeer Moss Eater © (2006-10-02 12:03) [180]

Неужели гуру SQL или их ученики не видят разницы между "Отчество не неизвестно" и "Отчества не существует"?

Эта разница существует в предметной области. А с точки зрения хранения данных никакой разницы нет.
Точнее эта разница есть только в одном случае:

раз в неделю админ выполняет запрос к контрагентам и получает список всех, у кого отчество is null (а не пустая строка). Дальше снаряжается экспедиция по адресам этих контрагентов с целью добыть отчество в личной беседе. Если нулл и пустая строка не различаются, и есть контрагенты без отчеств, система может зациклиться.

В остальных случаях разницы никакой нет.

:)

← →
evvcom © (2006-10-02 12:06) [181]

> [176] kaif © (02.10.06 11:49)

Ну, Ашот, не надо перегибать. Все-таки 0 - это вполне реальное значение. Даже визуально 0 и "нет значения, пусто" хорошо различаются. Пустая же строка и null визуально неразличимы. И какая мне разница, что реально запишется в базу null или пустая строка?
Да, Оракл отошел в реализации от стандартов, но сделал это ради увеличения быстродействия. С другой стороны, уже кто-то выше писал, что стандарты тоже люди писали.

← →
kaif © (2006-10-02 12:06) [182]

2 Игорь Шевченко © (02.10.06 11:53) [178]
OK
Возьмем описание крови доноров.

Группа, Резус, фактор Kell.

Группа принимает одно из 4 значений: 1,2,3,4
Резус принимает одно из двух значений (+,-) и его удобно записать в виде Char(1).
Фатор Kell может отсутствовать (пустая строка) или иметь некотлоые значения (например, + или KK)

Разница между тем, что Kell фактор отсутствует или не определен - вполне осязаемая. Реципиент умрет.
В ORACLE понадобится флаг. Ну куда без флага деться?
И если нужно сделать запрос по всем донорам, для которых не определяли Kell, то SQL-щик, незнакомый с особенностями ORACLE, сделает (думая ошибочно, что он не в сумасшедшем доме) запрос вида:

SELECT * FROM DONOR WHERE KELL IS NULL.

И получит фигню.

Если он не занимался у сенсея ORACLE, конечно.
:)

← →
kaif © (2006-10-02 12:08) [183]

2 Reindeer Moss Eater ©
Отчество Джнона Леннона - в студию.

← →
Игорь Шевченко © (2006-10-02 12:12) [184]

kaif © (02.10.06 12:06) [182]

> Группа принимает одно из 4 значений: 1,2,3,4
> Резус принимает одно из двух значений (+,-) и его удобно
> записать в виде Char(1).
> Фатор Kell может отсутствовать (пустая строка) или иметь
> некотлоые значения (например, + или KK)
>

Ну и неправильно, что пустая строка. Надо писать большими буквами "ОТСУТСТВУЕТ". В противном случае ты при выборке без критерия по этому полю получишь визуально неразличимую разницу между "не определен" и "отсутствует" во многих СУБД.

← →
Kerk © (2006-10-02 12:14) [185]

> [184] Игорь Шевченко © (02.10.06 12:12)

Причем на уровне представления данных. nvl() для того и придумали :)

← →
Reindeer Moss Eater © (2006-10-02 12:17) [186]

Отчество Джнона Леннона - в студию.

John Winston Lennon

Хотя конечно это не отчество :)
Разница-то какая?
Конкатенация имен Леннона в ведомости на зарплату в Apple нарисует правильный результат.
:)

← →
kaif © (2006-10-02 12:26) [187]

Игорь Шевченко © (02.10.06 12:12) [184]

Ну и неправильно, что пустая строка. Надо писать большими буквами "ОТСУТСТВУЕТ". В противном случае ты при выборке без критерия по этому полю получишь визуально неразличимую разницу между "не определен" и "отсутствует" во многих СУБД.

Вот для этого мужики и собрались и придумали стандарт SQL в 92 г.
Я подозреваю, что первоначально предполагалось, что этот язык освоят юзеры. Как минимум менеджеры звена выше низшего.
Но юзеры не захотели осваивать.
SQL стал языком программистов.
В этом и есть вся фигня. Так как все это вместо красивого и строгого соглашения стало зависеть от реализации, удобства, вкуса и т.п. То есть потеряло всякий смысл.
Программисту все равно - вставить флаг, выводить "ОТСУТСВУЕТ!!!!!!" или окрашивать весь экран в красный цвет. Ему все равно, как это хранить - лишь бы быстро работало и было ясно как.
Если программисты сами не хотят вырабатывать международных стандартов, то у нас одна перспектива - XML.
То есть делание вида о том, что существует стандарт.
А по сути - стандарта просто не будет никакого.
Каждый сам себе стандарт -
www.vasyaupkin.com/my_sql_standard/namespaces/fuckall/2006/01/01

← →
Игорь Шевченко © (2006-10-02 12:28) [188]

kaif © (02.10.06 12:26) [187]

> Вот для этого мужики и собрались и придумали стандарт SQL
> в 92 г.
> Я подозреваю, что первоначально предполагалось, что этот
> язык освоят юзеры. Как минимум менеджеры звена выше низшего.
>

Не совсем понял, причем здесь стандарт, для того, чтобы отличать в видимом представлении отсутствие строки и пустую строку.
Кстати, 0 для числовых полей визуально отличим от пустой строки. Может, поэтому 0 и не отождествляют с NULL ?

> [187] kaif © (02.10.06 12:26)

CREATE OR REPLACE VIEW view_kell AS
SELECT last_name, NVL(kell_value, "ОТСУТСТВУЕТ")
kell_value FROM kell;

Kerk © (02.10.06 12:29) [189]

> Разница между тем, что Kell фактор отсутствует или не определен
> - вполне осязаемая. Реципиент умрет.

Читать, в связи с

> Фатор Kell может отсутствовать (пустая строка)

В одном случае (пусто - эквивалент нул) программер вынужден либо заводить флаг в таблице, либо использовать значение "отсутствует" что бы пациент не умер.

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

Игорь Шевченко © (02.10.06 12:28) [188]
Кстати, 0 для числовых полей визуально отличим от пустой строки. Может, поэтому 0 и не отождествляют с NULL ?

Я часто прибегаю к таком приему:
MyField.DisplayFormat := "#,##0.00, -#.##0.00, "
Особенно если таблица широкая и в ней много нулей.
Так читабельнее.
Особенно если это отчет о продажах.
Здесь NULL тоже не будет отличаться от 0.
И что, теперь это довод?

kaif © (02.10.06 12:37) [192]

Что с пациентом делать будем для запроса по группе крови и резусу без учета фактора ?

> MyField.DisplayFormat := "#,##0.00, -#.##0.00, "
> Особенно если таблица широкая и в ней много нулей.
> Так читабельнее.

Ты волен делать все, что тебе угодно, но как в этом случае ты будешь отличать значения NULL и 0 в представлении ?

Если утверждается, что совершенно необходимо различать значения "пустая строка" (нет отчества вообще как у Леннона) и нулл (есть, но мы его не знаем), то я например могу заявить, что совершенно необходимо отличать числовое значение 5000 (оклад введен в поле главбухом) от значения 5000 (оклад введен в поле сантехником Потаповым).

Та же самая история. Значение одно и тоже, но мы зачем-то заморачиваемся программно на то, что не знаем как его интерпретировать.
То ли в самом деле нет отчества, то ли оклад может и не 5000 на самом деле.

Ладно, наплевали на стандарт. Но плюйте повсеместно. Почему для числовых NULL обрабатывается полностью, а для строковых как Бог на душу положит?

Вот, блин, ополчились!
Не нравится Оракл, не юзайте. На нас спрос будет выше. :)

Кто сказал, что стандарт попран?
Стандарт обязывает обеспечить особое волшебное значение null для всех типов данных. Вот для строк этим null значением и будет пустая строка.

2 Reindeer Moss Eater © (02.10.06 12:36) [191]
Согласен.
Поэтому я и рассматриваю эту проблему не под призмой реализации, а под призмой стандарта.

Так как обмен данными предполагает, что сапиенсы вырабатывают стандарты взаимопонимания.

И вероятность того, что кто-то "на том конце" не в курсе, что флаг KELL_IS_NOT_DEFINED означает то же самое, что в другой базе KELLA_NET выше, чем если оба программиста знают, что KELL IS NULL означает иное, чем KELL = "" и может для проверки своего предположения сразу сделать запрос вида:

SELECT COUNT(*), KELL FROM T1
GROUP BY KELL

и убедиться, что здесь есть именно та информация, на которую он рассчитывает.

Если мы переведем спор в плоскость реализации, то станет действительно все равно. Это будет дело вкуса.

Я придерживаюсь принципов нормализации.
А создание поля "Флага" нарушает эту самую нормализацию, так как образуется атрибут, неявно зависящий от другого атрибута и не зависящий от первичного ключа. Что значит неявно зависящий?
Означает, что ситуацию (KELL = "KK") and (KELL_NET = FALSE) невозможно интерпретировать иначе, как испорченные данные. А KELL IS NULL однозначно говорит о том, что имелось в виду. Существует логическая опасность различной интерпретации данных, если мы вносим вместо одного поля два поля для хранения какого-то одного атрибута сущности.
Тогда мы должны накладывать дополнительные констрейнты еще на стадии создания данных и поддерживать их на всем пути миграции таких данных.
ИМХО, это путь от нормализации - черт знает куда.
Мы получаем избыточность, если заводим флаг.
Мы должны уже запрещать некоторые сочетания.
А избыточность для меня - верный признак нарушения уже первой нормальной формы.

ИМХО, конечно.

Ну а как [194] и оклад в 5000 ?

NULL = ВНИМАНИЕ! ДАННЫЕ НЕ ПОЛНЫЕ! НЕ РАБОТАЙТЕ!
"" = ПОХРЕНУ! РАБОТАЙТЕ КАК ХОТИТЕ!

Есть разница?

Понятие NULL Найти похожие ветки