Дейт.Введение в БД. 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 © (21.01.04 12:51) [18] > Cкажем, "помехи" при чтении/понимании БД.

← →
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]

kaif © (21.01.04 14:11) [30]> В Delphi используешь nil? ;)

← →
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]

>kaif © (21.01.04 14:11)

Чувствуется философский подход :)

Это ОТСУТСТВИЕ ссылки.

← →
Карелин Артем (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, который он поместил в свою базу знаний, состоящую из одной таблицы с одним полем и одной записью.

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

> kaif © (21.01.04 14:21) [36]

В этом случае (on delete set null) полагаю разработчики IB имели ввиду ситуацию связи многие ко многим. В описанном вами варианте ахинея, совершенно согласен.

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

2 Johnmen © (21.01.04 14:25) [38]
А ты можешь создать запись со значением NULL в поле, которое ссылается на пустую таблицу через FOREIGN KEY DELETE SET NULL?
У меня были проблемы с этим делом.

Игорь Шевченко © (21.01.04 14:23) [37]

> FOREIGN KEY ON DELETE SET NULL.

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

Это не всегда возможно. Например, я хочу "отрезать" период с 1 января 2004 года. Накладные, датированные после 1 января 2004 года должны попасть в новую базу. Заказы, на которые они ссылаются, могут датироваться 1 июня 2003 года. Они уже действительно не нужны. Но накладные нужны. Мне приходится разрешать все ссылки и переносить такие заказы тоже. Только ради сохранения ссылочной целостности.

В конце концов я остановился на такой идеологии:
1.Я применяю ON DELETE CASCADE в отношениях шапка-детали документов (для упрщения удаления документа).
2.Я применяю простой FOREIGN KEY во всех ссылках на справочники и внутри справочной системы (для запрета на удаление используемого справочного элемента).
3.Я применяю такой же простой FOREIGN KEY в ссылках документов друг на друга (если они важны), препятствуя удалению, например, заказа, если по нему имеется накладная.

Если в справочниках я могу себе позволить "Пустой вектор", то в документах мне не нравится идея "Документа-заглушки" и поэтому я попадаю в ту ситуацию, которую описал.
Но нигде я не используя в ссылках поля, могущие принимать значение NULL. Так, по крайней мере, всем понятно, что происходит и как все будет работать.

← →
DiamondShark (2004-01-21 15:07) [43]

NULL нужны.
Хотя бы из соображений функциональной полноты.

← →
Johnmen (2004-01-21 15:10) [44]

>kaif ©

Я нравится философия на тему баз данных :)

Мне показалось, что ты не совсем осознаешь, что есть NULL. Точнее, не есть !
Нулл - это определение отсутствия. Но не значение !!! Отсюда понятно, что операция нулл=нулл просто абсурд !

← →
kaif (2004-01-21 15:23) [45]

2 Johnmen © (21.01.04 15:10) [44]
Можалуй ты прав.
Можно ли сказать, что небытия нет? Или небытие в данном случае есть? NULL это небытие данных. Реляционная теория баз данных разрешила спор греков о пустоте. Природа не боится пустоты, если существует NULL. Изобретение NULL настолько же велико, как открытие вакуума!
NULL это информационный вакуум.
А может и космический вакуум не равен самому себе?
Что мы вообще имеем в виду, говоря вакуум?
И можно ли ссылаться на вакуум? Нельзя. Поэтому NULL в ссылке должен пониматься как "отсутствие ссылки", а не как "пустая ссылка". Следовательно, FOREIGN KEY не должен содержать NULL. Так как он не либо содержит отсутствующих ссылок - либо он не форейн кей.

← →
kaif (2004-01-21 15:28) [46]

Поэтому в Дельфи nil это пустой указатель, а NULL - тип данных VARIANT. Однако в программном тексте на Object Pascal (в D6, по крайней мере), я могу спокойно убедиться, что:

if NULL=NULL then
ShowNessage("Природа программирования на pascal боится пустоты!");
Выведет сообщение на экран. И никаких IS.

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

> kaif © (21.01.04 15:28) [46]

Я думаю не стоит примешивать сюда Дельфи. Например, в Си nil отсутствует, его заменяет именно NULL.

Кроме того, Дельфи отработает NULL не всегда, так следующий код:

v := null; ShowMessage(IntToStr(VarAsType(v, varInteger)));

приводит к ошибке: "Could not convert variant of type (Null) into type (Integer)"

В теме идет речь об использовании NULL именно в вопросах проектированиия БД.

← →
Johnmen (2004-01-21 15:51) [48]

>kaif © (21.01.04 15:23)

:)))

Про небытие ничего сказать нельзя. Также, как ничего нельзя сказать про то, чего нет...

>Следовательно, FOREIGN KEY не должен содержать NULL

И не содержит ! Ничего не содержит !

← →
Mike B. (2004-01-21 16:07) [49]

Когда я ещё был маленький мальчик, мне было очень интересно почему нельзя делить на ноль.
То есть меня не удивлял сам факт запрета - уже тогда мне было понятно, что в этом мире вообще ничего нельзя делать интересного и приятного, а наоборот нужно делать скучное и противное. Умываться например нужно, а побрызгаться уже нельзя. Но мне было интересно, что же будет, если всё же на этот ноль разделить? Ничего не будет, отвечали взрослые, потому что нельзя делить, понимаешь, НЕЛЬЗЯ. Ну так я понимаю, что нельзя. В розетку например пальцы тоже совать нельзя, но всё равно ведь можно сунуть и тогда убьет током. И вообще, как правило все идиотские запреты взрослых как-то всё же обосновывались - глисты там подхватишь или дядя будет ругаться. А тут нельзя делить и всё. Видимо, думал я, тогда произойдёт что-то такое страшное, что даже взрослые боятся об этом говорить.
А потом, гораздо позже, я узнал что если разделить на ноль, получится Бесконечность. И ничего в этой Бесконечности нет страшного - так просто цыферка, восьмёрка на боку. Бывает плюс бесконечность, бывает минус. Её даже можно складывать и вычитать. Только Бесконечность плюс Бесконечность всё равно будет Бесконечность, хотя чисто по ощущениям, две Бесконечности конечно больше, чем одна. И Бесконечность минус Бесконечность тоже будет Бесконечность, небольшая, но всё равно без конца и края.
И совершенно непонятно, зачем от меня это так долго скрывали. Видимо люди ничего вообще не понимают в Бесконечности, а когда они чего-то не понимают, то это сразу нельзя.
За.... уже совсем.
(с) Дм. Горчев

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

← →
DiamondShark (2004-01-21 17:48) [50]

> Следовательно, FOREIGN KEY не должен содержать NULL

Не должен, но может.
Например, в таблице "Человеки" NULL в поле "Жена" будет означать "нету жаны".

← →
Тимохов (2004-01-21 18:10) [51]

Null нужен.
Я бы, правда, еще добавил бы к нему unassigned.
Вообще круто было бы...

← →
Sandman25 (2004-01-21 18:47) [52]

[51] Тимохов © (21.01.04 18:10)

Вместо unassigned можно добавить в таблицу дату_или_признак_присвоения.

[24] Polevi © (21.01.04 13:53)

Верю. Если Вам не нужно считать AVG().

← →
Fantasist (2004-01-21 20:32) [53]

> Я думаю не стоит примешивать сюда Дельфи. Например, в Си nil отсутствует, его заменяет именно NULL.

Не путайте понятие с условным обозначением. NULL в БД - это действительно отсутсвие значения. В С (как и в С++ и Делфи, да и пожалуй во всех остальных языках) такого понятия нет. Там есть понятие нуля. Хотя в С/С++ некоторые любят определять макрос NULL, но он на самом деле является обыкновенным числовым нулем (обычно имеющий тип void*). В Делфи nil - это тоже просто 0, но только для указателей. Ноль ведет себя как любое другое целое число.

В БД NULL-ов стараюсь избегать. Из моего опыта проблем с ними больше, чем пользы.

← →
Fantasist (2004-01-21 20:47) [54]

> Кроме того, Дельфи отработает NULL не всегда, так следующий код:

v := null;
ShowMessage(IntToStr(VarAsType(v, varInteger)));

приводит к ошибке: "Could not convert variant of type (Null) into type (Integer)"

А это уже работа с типом variant, спецификация которого включает себя понятие NULL. Оно похоже на понятие null из БД, однако variant не относиться к простым типам.

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