Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

foreign key и null в Interbase

Страницы: < 1 2
chyp © (2005-10-23 11:32:00)
Уважаемые коллеги, подскажите как разрешить 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) приводит к "ругани" сервера о недопустимости нулевых значений.

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

Спасибо!

Johnmen (2005-10-24 17:37:00) [21]
>msguns © (24.10.05 17:29) [17]

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

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

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

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

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

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

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

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

ANB (2005-10-24 16:09:00) [26]

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

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

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

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

Desdechado (2005-10-24 13:33:00) [28]
рекомендую все-таки не допускать NULL в ключевых полях, ибо:
1. в индексы NULL-значения не включаются, поэтому проверки fld is null приводят к PLAN NATURAL, что плохо
2. все NULL для сервера - разные, поэтому наложить UNIQUE можно, вот только строк с NULL Будет сколько угодно, да и сравнения с NULL по-другому писать приходится, что вовсе неудобно

Val (2005-10-24 13:31:00) [29]
я бы предположил баг, если честно.

chyp (2005-10-24 13:21:00) [30]
Спасибо всем за советы.
После долгих проб обнаружил интересную фичу: стоило поле внешнего ключа назвать другим именем, т.е:

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

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

Johnmen (2005-10-24 09:43:00) [31]

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

И что?

Fay (2005-10-24 02:05:00) [32]
2 chyp © (23.10.05 11:32)
Переходи на FB

msguns (2005-10-23 20:01:00) [33]
Убери каскадное удаление и будет она "пропускать" пустые значения для форинеров

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

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

chyp (2005-10-23 12:53:00) [35]

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

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

Sergey Masloff (2005-10-23 12:06:00) [36]
Тоже мне бином ньютона. Заведи в основной таблице "определенное" значение со смыслом NULL VALUE и ссылайся на него

msguns (2005-10-23 12:05:00) [37]
Возможно.

atruhin (2005-10-23 11:35:00) [38]
>>Такое возможно?
Нет.
Как вариант, убери FK и делай необходимую проверку в тригере.

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »