foreign key и null в Interbase

← →
chyp © (2005-10-23 11:32) [0]

Уважаемые коллеги, подскажите как разрешить null-значения в поле таблицы Interbase, объявленное как foreign key?

То есть имеем две таблицы:
CREATE TABLE TB_CATEGORY
(
ID_CATEGORY INTEGER NOT NULL,
NAME VARCHAR(20),
CONSTRAINT PCATEGORY_ID PRIMARY KEY (ID_CATEGORY)
);
CREATE TABLE TB_ITEM
(
ID_ITEM INTEGER NOT NULL,
NAME VARCHAR(20),
ID_CATEGORY INTEGER ,
CONSTRAINT PTEM_ID PRIMARY KEY (ID_ITEM),
FOREIGN KEY (ID_CATEGORY)
REFERENCES TB_CATEGORY(ID_CATEGORY) ON UPDATE CASCADE ON DELETE CASCADE
);

Теперь попытка внесения во вторую (зависимую) таблицу записи с пустым значением (NULL) в поле с аттрибутом FOREIGN KEY (ID_CATEGORY) приводит к "ругани" сервера о недопустимости нулевых значений.

То есть при заполнении зависимой таблицы хотелось бы помимо определенных в основной таблице значений иметь и неопределенные. Такое возможно?

Спасибо!

← →
atruhin © (2005-10-23 11:35) [1]

>>Такое возможно?
Нет.
Как вариант, убери FK и делай необходимую проверку в тригере.

← →
msguns © (2005-10-23 12:05) [2]

Возможно.

← →
Sergey Masloff (2005-10-23 12:06) [3]

Тоже мне бином ньютона. Заведи в основной таблице "определенное" значение со смыслом NULL VALUE и ссылайся на него

← →
chyp © (2005-10-23 12:53) [4]

> Возможно.
? если:
> Заведи в основной таблице "определенное" значение со смыслом
> NULL VALUE и ссылайся на него

Согласен, но, допустим, задача усложняется:
есть таблица "Юзеры", для нее связанная - "Адреса". И теперь для таблицы "Переписка": сначала выбирается Юзер, затем его адрес - что же теперь, для каждого юзера вводить дополнительную "пустую" запись адреса?

← →
Desdechado © (2005-10-23 18:45) [5]

2 chyp
Только что проверил на FB1.5.2 - твоя конструкция вполне работоспособна, никакой ругани не наблюдается. Сам я предпочитаю такими вещамине пользоваться, просто в справочнике завожу всегда "не определено" одной из строк (например, с кодом 0). Тогда все NOT NULL и индексы, кстати, лучше работают.
Может, эо у тебя компоненты какие-то ругаются, которые не знают о возможности NULL во внешнем ключе?

> для каждого юзера вводить дополнительную "пустую" запись адреса?
Зачем? Одну на всех.

← →
msguns © (2005-10-23 20:01) [6]

Убери каскадное удаление и будет она "пропускать" пустые значения для форинеров

← →
Fay © (2005-10-24 02:05) [7]

2 chyp © (23.10.05 11:32)
Переходи на FB

← →
Johnmen © (2005-10-24 09:43) [8]

> Fay © (24.10.05 02:05) [7]
> 2 chyp © (23.10.05 11:32)
> Переходи на FB

И что?

← →
chyp © (2005-10-24 13:21) [9]

Спасибо всем за советы.
После долгих проб обнаружил интересную фичу: стоило поле внешнего ключа назвать другим именем, т.е:

FOREIGN KEY (ID_CAT)
REFERENCES TB_CATEGORY(ID_CATEGORY) ON UPDATE CASCADE ON DELETE CASCADE

как все заработало!?

← →
Val © (2005-10-24 13:31) [10]

я бы предположил баг, если честно.

← →
Desdechado © (2005-10-24 13:33) [11]

рекомендую все-таки не допускать NULL в ключевых полях, ибо:
1. в индексы NULL-значения не включаются, поэтому проверки fld is null приводят к PLAN NATURAL, что плохо
2. все NULL для сервера - разные, поэтому наложить UNIQUE можно, вот только строк с NULL Будет сколько угодно, да и сравнения с NULL по-другому писать приходится, что вовсе неудобно

← →
msguns © (2005-10-24 16:04) [12]

>Desdechado © (24.10.05 13:33) [11]
>рекомендую все-таки не допускать NULL в ключевых полях

Ты не понял: ссылка на справочник не есть ключевое поле, а очень даже обнаковенное. И в нем вполне может быть NULL. Хоть в ИБ, хоть где угодно. А вот в спр-ке лона, знамо дело, ключевое (ID)

← →
ANB © (2005-10-24 16:09) [13]

> msguns © (24.10.05 16:04) [12]

Я бы согласился с Desdechado. 0 как пустое значение - очень удобно. И не нужны лефт джойны. И сравнения легче писать. Сам уже наступал на грабли. Были споры - как лучше - null или 0, практика показала, что 0 удобнее для программиста.

← →
Desdechado © (2005-10-24 16:45) [14]

2 msguns © (24.10.05 16:04) [12]
> ссылка на справочник не есть ключевое поле, а очень даже обнаковенное
это foreign KEY - перевести?

← →
msguns © (2005-10-24 16:50) [15]

>Desdechado © (24.10.05 16:45) [14]
>это foreign KEY - перевести?

Да я вроде и сам знаю несколько иностранных слов..
Ты вот мне объясни, каким боком в ссылающейся таблице поле, ссылающееся, например на справочник, должно быть непременно ключом ?

← →
Desdechado © (2005-10-24 17:11) [16]

2 msguns © (24.10.05 16:50) [15]
Вообще-то, про долженствование я не говорил, хотя и считаю, что ДОЛЖНО. Для сохранения логической целостности БД и данных в ней.
Это ж вообще самые азы. Я считал, что вы это знаете. Видимо, переоценивал...

← →
msguns © (2005-10-24 17:29) [17]

>Desdechado © (24.10.05 17:11) [16]
>Вообще-то, про долженствование я не говорил, хотя и считаю, что ДОЛЖНО. Для сохранения логической целостности БД и данных в ней.

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

Если "ДА", то будь так добр, дай невежде источник, где это написано.

← →
Johnmen © (2005-10-24 17:37) [18]

>msguns © (24.10.05 17:29) [17]

Совершенно верно. Вполне м.б.ситуация, когда ссылочное поле д.б. пустым.

← →
Desdechado © (2005-10-24 18:05) [19]

2 msguns © (24.10.05 17:29) [17]
Вот только передергивать не надо. В [14]-[16] речь шла о том, что это поле должно быть ключом, а не о том, что оно непременно должно быть заполнено значением из справочника.
А свое отношение с заполнению этого поля я уже отдельно сказал.

← →
chyp © (2005-10-25 23:59) [20]

> msguns © (24.10.05 17:29) [17]

именно про этот случай и идет речь.

← →
msguns © (2005-10-26 09:17) [21]

>Desdechado © (24.10.05 18:05) [19]
>Вот только передергивать не надо. В [14]-[16] речь шла о том, что это поле должно быть ключом, а не о том, что оно непременно должно быть заполнено значением из справочника.

В ссылочном справочнике это поле (ID записи спр-ка) должно быть не просто ключом, а единственным первичным ключом.
Если ты это хотел сказать, то надо было писать разборчиво, редиска ;)

← →
Zacho © (2005-10-26 09:52) [22]

msguns © (26.10.05 9:17) [21]
единственным первичным ключом.

Не обязательно, FK может ссылаться и на UNIQUE. Правда, насколько помню в этом случае толи баги какие-то в IB были, толи ещё что-то неприятное :), в общем - теоритически возможно, но не рекомендуется.

← →
Johnmen © (2005-10-26 10:11) [23]

>Zacho © (26.10.05 09:52) [22]

Я так, помнится, делал (на юник). Ещё на IB4.xx. Глюков не было. И, как говорят, до сих пор нет...:)

← →
Zacho © (2005-10-26 10:22) [24]

Johnmen © (26.10.05 10:11) [23]

Возможно. Сам я так никогда не делал, но смутно помню, что лет 7 назад в фидо обсуждались какие-то глюки, связанные с FK на UNIQUE

← →
Desdechado © (2005-10-26 11:48) [25]

msguns © (26.10.05 09:17) [21]
Не проснулся еще что ли? :) Мои посты вместе надо читать и в общем контексте, а не по отдельности.
Я говорил о внешнем ключе, о FOREIGN KEY, о поле с ним. Оно не обязано быть заполненным, но признак FK должно иметь (если логически ссылается на справочник), иначе логическая целостность БД нарушится.

Zacho © (26.10.05 10:22) [24]
> глюки, связанные с FK на UNIQUE
Тоже не пользуюсь этим, но подозреваю, что причина в том, что, как я уже говорил, все NULL - разные, и можно вставить много NULL в UNIQUE-поле, и NULL-FK будут иметь проблемы с определением, на какой NULL-UNIQUE им ссылаться.

← →
Zacho © (2005-10-26 12:03) [26]

Desdechado © (26.10.05 11:48) [25]
можно вставить много NULL в UNIQUE-поле

Нельзя. UNIQUE можно создать только для NOT NULL полей.

В Data Definition Guide же всё подробно описано, и про UNIQUE и про FK.

Правда, в FB1.5 в UNIQUE CONSTRAINT допустимы NULL"ы. Не знаю, можно ли там создать FK, ссылающийся на такой констрейнт, но по логике должно быть нельзя, поскольку бессмысленно.

Zacho © (26.10.05 12:03) [26]
в моем посте [5] указан именно FB1.5.2
>Не знаю, можно ли там создать FK, ссылающийся на такой констрейнт
Только что создал.
Но согласен - глупости какие-то.

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

> Desdechado © (26.10.05 12:24) [27]

Ключевые, но не FK поля, ссылающиеся на них. Null вполне допустим, но неудобен потом при использовании.

2[29] ANB © (26.10.05 14:15)
> Null вполне допустим, но неудобен потом при использовании.

Отчасти - да. Но, ИМХО, есть определенная прелесть в этом "неудобстве". 8-)

Вводя в справочник нечто вроде ID=0 Value="None" ты "обрекаешь" себя на отдельную заботу об этой записи. Она дожна быть, и должна быть именно такой по форме и содержанию, т.е. смысл ее должен оставаться неизменным. А что, например, запретит юзеру поменять "None" на "Иванов". Все нормально. А вся программа летит вверх тормашками.
А нет ссылки - это всегда нет ссылки.

2[31] Андрей Жук © (26.10.05 14:46)
Это опять отдельная обработка по "неотображению". Чем тогда это лучше NULL? Всегда найдутся люди, которые сумеют отобразить "неотображаемое".

2 ANB
> Null вполне допустим
Я разве говорил обратное? Допустим, но я считаю это вредным.

2 Sergey13 © (26.10.05 14:51) [32]
> Всегда найдутся люди, которые сумеют отобразить "неотображаемое"
А также удалить неудаляемое, изменить неизменяемое и подключиться, куда нельзя. От админа не защитишься, дураки есть везде, а хакеры - это их помесь :)
Припомни ветку ANB в "потрепаться" про защиту от админа.

Desdechado © (26.10.05 12:24) [27]
в моем посте [5] указан именно FB1.5.2

Но я-то в [24] писал о событях 7-ми летней давности, когда FB ещё и в проекте не было :) А в IB тогда (а может и сейчас, не знаю) UNIQUE мог быть только NOT NULL

А насчёт FB 1.5 - мне никогда не нужны были NULL в UNIQUE, но сейчас ради эксперимента попробовал. Создал две таблицы, T1 и T2. В первой - nullable поле T1_ID с UNIQUE CONSTRAINT, во второй - поле T1_ID_REFERENCE с FK, ссылающимся на поле T1_ID в таблице T1. Добавляю в таблицу T1 несколько записей с T1_ID=NULL. Всё Ok. Добавляю во вторую несколько записей с T1_ID_REFERENCE=NULL. Всё Ok.
Маразм !!! Ну и как понять, на какую именно запись из T1 ссылается запись из T2 ???
Либо я чего-то не понимаю, либо в FB 1.5 явное противоречие с концепцией ссылочной целостности.

← →
Val (from Kiev) (2005-10-26 17:40) [35]

почему маразм? нет значения ключевого поля в дочерней таблице - нет ссылки. ведь результат операции с null не маразм, не так ли?

И так. Имеем список чего нибудь, ну пусть сотрудником с необязательной ссылкой на какой нибудь справочник, ну пусть в/звание для военнообязанных. Если пустую ссылку я заменю 0, то могу писать запросы с обычными джойнами и все будет нормально. Если же засуну null, то мне придется использовать лефт джойны, а например оракл слегка ограничивает их использование (цепочки не допускает). Вывернуться можно, но зачем ?

Val (from Kiev) (26.10.05 17:40) [35]

Ну с этой точки зрения действительно не маразм. Но null - это не только "нет значения", но и "значение есть, но не известно". Вот тогда - маразм. Поскольку получается, что в "родительской" таблице есть возможно несколько записей, на которые ссылается запись в "дочерней".
А если, как было раньше, FK может ссылаться только на первичный или потенциальный ключ - таких неоднозначностей не возникало. Либо есть ссылка, либо нет. А если FK ссылается на nullable UNIQUE - то получается, что возможно ссылка есть, а возможно нет. А это, имхо, потенциальный источник багов.

msguns © (26.10.05 17:42) [36]
Зачем ? Шоб було ?

А просто удобно так. Может уберечь от потенциальных багов и неоднозначностей, особенно неопытных разработчиков.

Кстати, насколько помню, такой "монстр" как Крис Дейт, был вообще против использования NULL.

foreign key и null в Interbase Найти похожие ветки