Дейт.Введение в БД. Null

← →
Alex_Bredin (2004-01-21 10:44) [0]

Давно интересует вопрос- в упомянутой книге автор настойчиво убеждает читаталя, что логика БД, в которой присутствуют Null - значения неоправданно усложнена. И рекомендует при разработке избегать неопределенных значений в БД. Такой подход якобы позволяет значительно упростить и ускорить работу.Хотелось бы знать - пытался ли кто-нибудь следовать рекомендациям Дейта и что из этого вышло.Приветствуются также любые соображения по этому поводу.

← →
stone (2004-01-21 10:47) [1]

Наверное тут еще надо учитывать СУБД. Я работаю с MSSQL, там значения NULL в любом месте не составляют проблемы, функция IsNull приводит его к любому значению по умолчанию. Есть случаи когда использование NULL довольно выгодно.

← →
Johnmen (2004-01-21 10:52) [2]

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

← →
Nikolay M. (2004-01-21 10:55) [3]

В теории, на академическом уровне - я согласен. Но на практике иногда имеет место быть, что иногда тащит за собой проблемы типа SELECT SUM(qnty) (= NULL). В таких случаях, наверное, вместо NULL лучше использовать заведомо невстречающееся значение (например, для количества чего-либо: -1).
Короче, имхо, зависит от задачи.

← →
Danilka (2004-01-21 10:56) [4]

Хм, я кроме как примечание у документа/справочника или еще чего, не могу представить поле, которое выгодно делать не "not null".

← →
Dok_3D (2004-01-21 11:01) [5]

Значения какого-то поля в таблице - есть множество.
Значение, отличное от Null - говорит о том, что этот элемент множеству принадлежит и может участвовать во всех операциях, связанных с этим множеством.
Null предначначен для сигнализации и том, что этот элемент в множестве не присуствует.

А вот прикладная польза Null - это действительно можно оспорить. На мой взгляд - он нужен.

← →
Johnmen (2004-01-21 11:02) [6]

>Nikolay M. © (21.01.04 10:55) [3]
>проблемы типа SELECT SUM(qnty) (= NULL).

Нет такой проблемы...:)

>Danilka © (21.01.04 10:56)

[2]

← →
Danilka (2004-01-21 11:05) [7]

[6] Johnmen © (21.01.04 11:02)
не совсем понял что за зверь: поле-числовая характеристика
:))

← →
asp (2004-01-21 11:06) [8]

Без NULL"а было бы очень непросто обойтись.
Первый пришедший на ум пример - незаполненное поле в составе внешнего ключа.

← →
Johnmen (2004-01-21 11:11) [9]

>Danilka ©

Поле, в котором лежат, напр., числовые характеристики измерений датчика. Если нулл, то значение характеристики отсутствует.
Для поле, входящих в FK - отсутствие связи.
См. также Dok_3D © (21.01.04 11:01) [5].

← →
Danilka (2004-01-21 11:20) [10]

[9] Johnmen © (21.01.04 11:11)
понял.

← →
Sergey13 (2004-01-21 11:32) [11]

2Alex_Bredin © (21.01.04 10:44)
Просто теоретически (да и практически) с неопределенностью гораздо сложнее работать чем с определенным значением. Т.е. неопределенность надо как то интерпретировать. А интерпретация зависит от многих факторов. Но все это с точки зрения самой СУБД, на низком уровне так сказать.
С точки зрения прикладной задачи часто проще иметь NULL.

← →
kaif (2004-01-21 11:44) [12]

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

← →
Delirium (2004-01-21 11:48) [13]

Весть вопрос в уровне нормализации базы, разумеется в высоконормальных БД, NULL как таковой - просто невозможен. Однако, много-ли вы видели таких баз - где каждый справочник состоит только из 2-х полей, ключа и значения?

← →
asp (2004-01-21 12:33) [14]

kaif © (21.01.04 11:44) [12] > Набив, думаю, поменьше шишек, пришел к абсолютно другому. :)
Поля как NOT NULL объявляю только ключевые. На остальные в случае необходимости ставлю CHECK (FIELD IS NOT NULL). Так легче "читать БД".
То есть пример:
Есть таблица:
CREATE TABLE EXP.DOC_TITLE
(ID CHARACTER(13) FOR BIT DATA NOT NULL DEFAULT "",
OPERATION SMALLINT CHECK (OPERATION IS NOT NULL),
AFFILIATE INTEGER CHECK (AFFILIATE IS NOT NULL),
ORD_NUM BIGINT DEFAULT 0 CHECK (ORD_NUM IS NOT NULL),
PRIMARY KEY(ID),
FOREIGN KEY(OPERATION) REFERENCES EXP.OPERATION(ID) ON DELETE RESTRICT,
FOREIGN KEY(AFFILIATE) REFERENCES EXP.AFFILIATE(ID) ON DELETE RESTRICT)

И к ней уникальный индекс:
CREATE UNIQUE INDEX EXP.DOC_TITLE_ORD ON EXP.DOC_TITLE (OPERATION ASC, AFFILIATE ASC, ORD_NUM ASC)

В случае объявления полей AFFILIATE, OPERATION, ORD_NUM как NOT NULL, появляется вопрос что считать первичным ключём. (ID) или (OPERATION, AFFILIATE, ORD_NUM).

Вот вторая проблема (asp © (21.01.04 11:06) [8]) NOT NULL"а. INHO. :)

← →
Nikolay M. (2004-01-21 12:36) [15]

> Johnmen © (21.01.04 11:02) [6]
> >Nikolay M. © (21.01.04 10:55) [3]
> >проблемы типа SELECT SUM(qnty) (= NULL).
> Нет такой проблемы...:)

Хм. А я думаю, откуда берутся вопросы вроде "я складываю числа, одно из которых - НУЛЛ и в результате получаю НУЛЛ?" :)

← →
Карелин Артем (2004-01-21 12:38) [16]

У меня наоборот, поля с Null имеют свое, особое назначение. А как еще к примеру указать тот факт, что к примеру даты чего-либо нет вообще?

← →
Danilka (2004-01-21 12:39) [17]

[14] asp © (21.01.04 12:33)
чего-то я тебя не понял...

> В случае объявления полей AFFILIATE, OPERATION, ORD_NUM
> как NOT NULL, появляется вопрос что считать первичным ключём.
> (ID) или (OPERATION, AFFILIATE, ORD_NUM).

В смысле? У кого появляется такой вопрос?

← →
kaif (2004-01-21 12:51) [18]

2 Delirium © (21.01.04 11:48) [13]
У меня практически все справочники такие.

2 asp © (21.01.04 12:33) [14]
Где появляется вопрос о том, что считать первичным ключем?
Я, смотря на таблицу вроде

CREATE TABLE(
...
PRIMARY KEY(...)
UNIQUE (...)
)

понимаю, что первичный - тот, который PRIMARY, а второй ключ - так называемый альтернативный. Это нормальная практика. Особенно если все первичные ключи суррогатные (а обычно так оно и бывает).

Поясните, в чем, собственно проблема. Возможно, я просто не понимаю.

← →
Sandman25 (2004-01-21 13:00) [19]

[15] Nikolay M. © (21.01.04 12:36)

При Sum(Field) игнорируются те Field, которые NULL

А вот Field1+Field2 возвращает NULL, если хотя бы одно из этих полей NULL

← →
Johnmen (2004-01-21 13:09) [20]

>Nikolay M. © (21.01.04 12:36)

Так то ты складываешь, а то SUM складывает...:)))
Sandman25 © (21.01.04 13:00)

← →
Polevi (2004-01-21 13:29) [21]

использую Null только для строковых полей

← →
Sandman25 (2004-01-21 13:45) [22]

[21] Polevi © (21.01.04 13:29)

Как раз для строковых есть естественное NULL-подобное значение - пустая строка, которая в 99% случаев с точки зрения клиента неотличима от NULL. А вот для числовых данных не всегда можно заранее сказать, каких данных никогда не будет. Недавно нарвался на баг в ListBoxItems при добавлении id = -1 из таблицы. Так что я NULL использую везде, где только могу... Точнее, везде, где это нужно :)

← →
hCat (2004-01-21 13:53) [23]

> Карелин Артем © (21.01.04 12:38) [16]
> У меня наоборот, поля с Null имеют свое, особое назначение.
> А как еще к примеру указать тот факт, что к примеру даты
> чего-либо нет вообще

Применительно к датам - сверхмалые "01.01.0001" и свербольшие "01.01.4000" вместо Null. Минусом такого подхода является проблема 4000-го года, плюсом простота запроса

select
...
from ...
where ...
and :EffectiveDate between Date_From and Date_Till

← →
Polevi (2004-01-21 13:53) [24]

>Sandman25 © (21.01.04 13:45) [22]
для числовых полей использую 0 по дефолту
ни разу не было ситуации когда этот вариант не работал
возможно они есть, но не в моих случаях

← →
myor (2004-01-21 13:55) [25]

null - полезная штука.
другое дело - организация обработки null в субд и использование null разработчиками бд.
Johnmen © (21.01.04 10:52) [2]
+
asp © (21.01.04 11:06) [8]
+
imho
null не нужно "интерпретировать" (Sergey13 © (21.01.04 11:32) [11] ), нужно правильно определять значения данных (по возможности задавать значения по умолчанию), т. е., предварительно интерпретировать значение как null или 0 или "", а не значение как null, а потом null как 0 или "". и тогда не будут возникать проблемы типа SELECT SUM(qnty) (= NULL) (Nikolay M. © (21.01.04 10:55) [3] ).

← →
kaif (2004-01-21 14:00) [26]

Пожалуй, стоит обсудить эту тему отдельно для:
1.Полей, предназначенных для FOREIGN KEY
2.Числовых полей
3.Строковых полей
4.Полей с датами, временем и TIMESTAMP (больная тема для приверженцев NOT NULL в сочетании с DEFAULT)
5.Полей в таблицах справочников

← →
hCat (2004-01-21 14:01) [27]

> Alex_Bredin © (21.01.04 10:44) [0]

IMHO это цель к которой стоит стремится, но нельзя рассматривать эту рекомендацию как самоцель. Расшифрую - вы должны аргументировать, хотя бы себе самому, почему значение данного конкретного поля может быть неопределенным. Появление такого аттрибута в сущности может являться признаком того, что вы свели в одну сущность аттрибуты различных сущностей.

← →
Карелин Артем (2004-01-21 14:01) [28]

hCat (21.01.04 13:53) [23]
Вообще-то проще будет IS NULL или =NULL.

← →
asp (2004-01-21 14:05) [29]

← →
kaif (2004-01-21 14:11) [30]

Я, например, столкнулся с противоречиями в FOREIGN KEY, если допускался NULL. Мне пришлось отказаться от NULL в FOREIGN KEY и ввести понятие "нулевого вектора" во всех справочниках. Типа запись ID=0, NAME="". Неудаляемая. У меня уже был спор на эту тему на форуме... В один момент меня даже переубедили. Но потом я все равно столкнулся с новыми проблемами. И придерживаюсь этого простого ограничения. Возможно, я упускаю какой-то важный момент. Возможна ли ссылка на таблицу, в которой нет записи? Допустим есть ссылка и она NULL. Это и есть ссылка на несуществующую запись? Или это ссылка на запись NULL? Пустой указатель не то же самое, что неопределенный указатель. Что об этом говорит стандарт? Нельзя же здесь полагаться только на эксперимент? Возможно это невежество. Воспримите как крик души и не бейте.

← →
asp (2004-01-21 14:14) [31]

← →
hCat (2004-01-21 14:15) [32]

> Карелин Артем © (21.01.04 14:01) [28]
> hCat (21.01.04 13:53) [23]
> Вообще-то проще будет IS NULL или =NULL.

Не понял. Что именно будет проще - запрос, хранение или модифицирование ?

← →
Johnmen (2004-01-21 14:16) [33]

← →
Карелин Артем (2004-01-21 14:16) [34]

hCat (21.01.04 14:15) [32]
Усе вместе. Правда это субьективная вещица.

← →
hCat (2004-01-21 14:19) [35]

> kaif © (21.01.04 14:11) [30]

Относительно такой практики со справочниками согласен. Если говорить про FOREIGN KEY вообще, то о каких именно противоречиях идет речь ?

← →
kaif (2004-01-21 14:21) [36]

Допустим речь идет об IB. В IB декларативной ссылочной целостности придается большое значение и имеются хорошие средства для этого.
Итак, я объявляю FOREIGN KEY ON DELETE SET NULL.
Что это значит? Это значит, что если я удалю запись из "главной" таблицы, в "подчиненной" значение поле станет NULL. То есть записи в главной таблице нет, а в "подчиненной" - есть.
Теперь зададимся вопросом. Если в таком представлении данных есть какой-то смысл (философский), то должна быть возможность добавить такую запись в "подчиненную" таблицу, что она не имеет представителя в "главной". Однако FOREIGN KEY этого сделать не даст. Налицо противоречие. Допустим, я могу создать заказ, а к нему (ссылающуюся на него) накладную отгрузки. Предположим, я могу удалить заказ, при этом накладная больше не ссылается ни на какой заказ. Следовательно в базе я допускаю такое положение вещей. Допустим мне это действительно зачем-то нужно (удаление старых документов, к примеру). Однако в результате я имею разд накладных, не ссылающихся ни на один заказ и возникает вопрос, почему я не могу создать такую накладную "в лоб"? Хотя могу создать точно такую же с помощью хитроумной манипуляции: "создать псевдозаказ, к нему накладную, а потом заказ удалить" ? Или я чего-то не догоняю, или здесь налицо абсурд.

← →
Игорь Шевченко (2004-01-21 14:23) [37]

> FOREIGN KEY ON DELETE SET NULL.

Для этой задачи (с накладными) разумнее объявлять CASCADE

← →
Johnmen (2004-01-21 14:25) [38]

← →
hCat (2004-01-21 14:35) [39]

> hCat (21.01.04 14:15) [32]
>
>
> Не понял. Что именно будет проще - запрос, хранение или
> модифицирование ?

> Карелин Артем © (21.01.04 14:16) [34]
> hCat (21.01.04 14:15) [32]
> Усе вместе. Правда это субьективная вещица.

Нет не все. Модифицирование заметно сложнее (оговорку смотри ниже), запрос проще и потребует меньше ресурсов, хранение потребует большего объема.
Оговорка: если реализуется след задача - есть сезонная цена например с 1.12.03 по 31.03.04, а так же с 1.04.04 до скончания времен другая, а вам надо сделать так, чтобы на зимние школьные каникулы (с 29.12.03 по 15.01.04) была третья цена, то реализация в моем варианте будет ИМХО проще.

update ... set date_till="29.12.03" where "29.12.03" between Date_From and Date_Till; update ... set date_from="15.01.04" where "15.01.04" between Date_From and Date_Till; insert into (Date_From, Date_Till, ...) values ("29.12.03","15.01.04", ...);

← →
kaif (2004-01-21 14:40) [40]

Что касается философии самого NULL, то я считаю, что это очень глубокомысленная вещь. Достаточно заметить, что утверждение NULL=NULL ложно. И ложно утверждение NULL<>NULL. Если бы во времена Аристотеля можно было бы до такого додуматься, планета сейчас выглядела бы иначе... Здесь мы покидаем привычную нам (в математике) систему обозначения вещей. Для Канта, например, очевидно, что A=A. И так для любого сивола. Математики любят с этим играться (с такими выкладками). Даже великий Рассел из-за этого недоразумения путается в парадоксе про критянина, говоря, что парадокс о критянине можно свести к утверждению "я лгу". Нельзя свести. И я горжусь тем, что создатели реляционной теории баз данных на практике решили проблему, введя понятие NULL. "Неизвестно что" не может быть равно самому себе. Как это ни странно. Поэтому утверждения типа "нечто равно себе" и "нечто тождественно себе" суть два разных утверждения.
Мне кажется, что:

IS NULL - тождественность
= NULL - равенство

Если мы не знаем чего-то, то единственное, что мы знаем, так это то, что мы ничего не знаем. Можно ли это называть знанием? Есть ли здесь парадокс? Изобретатель понятия NULL - сам Сократ, ИМХО. Просто он это сформулировал, как парадокс. Для всех. Кроме него самого. А то, что парадокса нет, вылезло не в метафизических или логических рассуждениях, а когда попытались работать с информацмей на практике. И стало ясно, что из того, что мы чего-то не знаем еще нельзя делать вывод о том, что мы уже что-то узнали, ура!
При выполнении SELECT незнание (NULL) из одного места передается в другое. Передача сообщения о незнании...
Говоря в стиле Copyr25, со времен Сократа до нас дошел NULL, который он поместил в свою базу знаний, состоящую из одной таблицы с одним полем и одной записью.

Дейт.Введение в БД. Null - да или нет? Найти похожие ветки