Ссылочная целостность...

← →
kaif (2003-08-07 19:20) [0]

Вот хочется пообсуждать.
Существует понятие ссылочной целостности (СЦ) в базах данных. Декларативная СЦ реализуется серверами с помощью ограничительных ключей FOREIGN KEY (например, в InterBase этим часто пользуются разработчики).
Допустим у нас имеется документы (инвойсы), позиции которых хранятся в таблице INVOICE_ITEMS. Допустим у нас имеются также документы поставок, позиции которых хранятся в таблице DELIVERED_ITEMS. Логично установить ссылочную целостность вида
DELIVERED_ITEMS -> INVOICE_ITEMS. Я собственно так и поступаю. Однако в реальности вместо товара А могут прислать товар B (сдуру) или вообще прислать товар, который не относится ни к какому инвойсу. Учесть такой товар в таблице DELIVERED_ITEMS будет невозможно, если объявлена ссылочная целостность.
Сталкиваясь с подобными проблемами, я стал подумывать о введении специального понятия "пустой документ" или "нулевой документ", на который можно было бы завязывать такие ссылки...
Интересно, использовал ли кто-нибудь из участников форума в своей практике такое понятие?
И вообще, кто что об этом думает?

← →
DiamondShark (2003-08-07 19:33) [1]

Не "пустой документ", а вполне определённый тип документа. Назвать, скажем, "Акт приёмки" (у нас так назывался). И в нём уже регистрировать разногласия между выписанной накладной и реально доставленным товаром.
Ключи-то здесь причём?

← →
Desdechado (2003-08-07 19:38) [2]

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

← →
MsGuns (2003-08-07 19:59) [3]

Не совсем понял терминологию. А именно, что подразумевается под словом "инвойс" и под словом "поставка". Если речь идет о выписке счетов или даже накладных покупателю, опережающих реально пришедший от поставщика товар (т.е. когда документы ходят после того, как пролетает товар), то в таких случаях используется еще понятие "Заказ" (или договор) с поставщиком, в котором перечень товара, который поставщик должен поставить в течение определенного времени на определенных условиях (надеюсь, меня понимают). В таких перечнях товар берется из справочника товаров, никак не связанных с конкретными приходами и не имеющего, в частности, учетных цен. Счет или накладная на отгрузку покупателю выписывается или с реальных приходов или с вот этих заказов. Во втором случае нет суммы учетной (естественно, т.к. не было документа поставки), но это не мешает определить сумму реализации и даже НДС, которую следует кредитовать по данной сделке. А когда уж доходит дело до отчета (бухгалтерского), тогда такие "голые" строки заполняются подоспевшими приходами.

Если я правильно понял ;))

← →
kaif (2003-08-07 20:01) [4]

2 DiamondShark © (07.08.03 19:33)
То есть ты полагаешь, что такая ситуация свидетельствует о том, что в учетной схеме отсутствует некоторый важный документ? Мне этот подход нравится. Но все равно проблема перемещается в акт приемки. Либо этот документ должен хранить позиции в двух таблицах, одна из которых связана непосредственно с инвойсами, а другая - рыхлая.

← →
kaif (2003-08-07 20:27) [5]

2 MsGuns © (07.08.03 19:59)
Нет, ситуация несколько иная. Допустим имеется четкая последовательность документов:
1.Заказ клиента
2.Размещение его у производителей (перезаказ)
3.Подтверждения от производителей, что перезаказ принят к производству (в каждом подтверждении подтверждается некоторое подмножество позиций перезаказа)
4.Инвойс, выставляемый производителем в который собираются уже произведенные и готовые к отпраке позиции из разных заказов.
5.Поставка (множество инвойсов, все позиции которых загружаются в транспортное средство)
6.Спецификация поставки (список всего, что идет в данной поставке со ссылками на перезаказы). (Этот документ строится автоматически)
7.На складе спецификация поставки сверяется с фактически пришедшими позициями и вот здесь возможны проблемы.
8.Отгрузка клиенту позиций, которые в данный момент подоспели (из числа заказанных им ранее и уже пришедших на склад)
---------------------------------
Красивое решение задачи:
1 .Отношения один ко многим:
Заказ клиента -> Размещения -> Подтверждения <- Инвойсы <- Спецификация поставки <- Отгрузка со склада клиенту

То есть в общем случае (что касается позиций документов):
1. один заказ имеет несколько размещений
2. одно размещение имеет несколько подтверждений
3. одно подтверждение имеет несколько инвойсов
4. один инвойс имеет одну поставку от производителя
5. одна поставка имеет несколько отгрузок клиенту.

Разумеется, все пронизано ссылочной целостностью. Однако это приводит к тому, что позиции, пришедшие в поставках (это большая редкость) и не вошедшие ни в один инвойс приходится оприходовать за пределами данной схемы. Это конечно не проблема, но хотелось бы разобраться в идеологии и традиции реляционного подхода и его применимости в этом случае (сверка того, что есть с тем, что должно было быть).
Что касается справочников, то у меня во всех справочниках имеется такой "нулевой вектор". А в документах я избегаю это решение применять, так как если юзеру можно объяснить, что такое "пустой элемент справочника", то объяснить, что такое "пустой документ" достаточно проблематично.
Если меня спросят, зачем здесь ссылочная целостность, отвечу: для того, чтобы сдуру что-то не удалили из тех позиций, что уже используются в дальнейшем движении.

← →
DiamondShark (2003-08-08 10:57) [6]

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

← →
Reindeer Moss Eater (2003-08-08 11:26) [7]

СЦ не подразумевает, что некое поле всегда содержит верную ссылку на существующий ключ. Это некое поле может иметь и NULL значение.

← →
Sergey13 (2003-08-08 11:36) [8]

Да, наворочано! ИМХО, если бы было больше нормального русского языка вместо "инвойсов" было бы понятнее. 8-) Но это так, к слову.
Я наверное присоединюсь к MsGuns © (07.08.03 19:59) (что то у нас часто мнения стали совпадать 8-)
Тут проблема ИМХО не в СЦ, а в правильной организации бизнес процессов. Я сейчас как раз занимаюсь подобной проблемой у себя. У нас склад и снабженцы по большому счету никак не связаны, кроме как по телефону. Так уж получилось, недоработали. Т.е. снабженец что то заказал, а при приходе на склад уже кладовщица тетя Дуся решает что же это такое и куда же это отнести. И относит...

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

Конечно "нулевые документы" это выход, но больше похожий на латание дыр. При приличном обороте на складе разобраться потом с этими зануленными товарами - та еще проблема, которой у нас например уже занимается отдельный человек.

← →
MsGuns (2003-08-08 11:48) [9]

Почему-то согласен с DiamondShark © (08.08.03 10:57)
Не покидает мысль, что все как-то свалено в кучу. Возможно, это только кажется, но ! В любом случае я не стал бы смешивать в один салат номенклатуру заказчика как он привык с номенклатурой поставщика. Часто это весьма не одно и то же. А сделал бы свой, "транзитный" номенклатурник, через который и устанавливал бы ссылочки на конкретные товары.

Кроме того, принятая в этой конторе система "инвойсов" (как я понял, предварительных фактур по готовящимся к отгрузке перечням в разрезе сделанных группировок - заказов), возможно, заимствована откуда-то. Очень похоже на западные системы учета и комплектации. Мне приходилось иметь дело с парочкой подобных - гемор ужасающий ! Не случайно у них так раздуты админ.штаты.

← →
kaif (2003-08-08 13:08) [10]

2 Reindeer Moss Eater © (08.08.03 11:26)
СЦ не подразумевает, что некое поле всегда содержит верную ссылку на существующий ключ. Это некое поле может иметь и NULL значение.

Я не нашел способа объявить это в IB.
========================================
2 All
Поймите, я вообще обсуждаю эту проблему, а вовсе не конкретную задачу. У данной задачи уже есть вполне определенное решение (оно выработалось, когда еще не было никакой программы): если присылается дурная позиция, которую вообще никто не заказывал, она просто кладется на склад или в магазин как таковая или списывается к чертовой матери. Если же вместо какой-то позиции присылается иная, то заказ считается невыполненным и производитель штрафуется.
Проблем с разными номенклатурами у данного заказчика нет.
--------------------
Меня всего лишь интересует отношение к "нулевым документам", как способу разрешения некоторых противоречий между жесткой ссылочной целостностью и реальной жизнью. Я сам склоняюсь к мнению, что такие документы вредны, просто хотелось услышать еще голос других разработчиков в пользу такого подхода.

2 MsGuns © (08.08.03 11:48)
Да, схема взаимодействия с иностранным производителем.
По большому счету все равно как это называть. Пусть это будет Счет-фактура, которую надо оплатить прежде, чем товар будет выслан. Предположим, мы оплатили такой документ, а потом приходит всякая хрень. Еще ладно, если каких-то позиций недостает. Можно в таблице, хранящей счета-фактуры таких поставок добавить поле "недостающее кол-во по данной позиции". И выставлять финансовые претензии потом. Однако ситуация совершенно меняется, если прислали что-то, чего вообще не было в исходном счете-фактуре или прислали вместо одного товара совершенно другой. Представьте себе, что товары достаточно эксклюзивные (дорогие коллекции) и в всегда присылаются со ссылкой на первичный заказ клиента. Это не просто номенклатура.
Говорить, что проблема не имеет отношения к ссылочной целостности неверно. Она проявляется только при организации ссылочной целостности. Если существует бизнес-правило, что любая приходящая позиция относится к какому-то заказу какого-то клиента но это правило нарушается изредка из-за ошибочно присланных позиций, то возникает вопрос, как все эти факты хранить в базе данных. И если позиция приходит со ссылкой (ссылка прямо помечена в инвойсе!) на исходный заказ, а в том такой позиции отродясь не было, то непонятно, что вставлять в такое поле (ссылка на заказ), если сервер жеско отслеживает связи таким способом, чтобы выполнялось основное бизнес-правило.
То есть сформулирую проблему проще. Разработка реляционных структур сводится к реализации бизнес-правил. Все хорошо. Но изредка бизнес-правила тем не менее не выполняются. Я нигде не встречал ответа на вопрос, как возможны бизнес правила, которые иногда не выполняются и какова традиция реализации таких систем (с редкими "исключениями" из бизнес-правил)?

← →
MsGuns (2003-08-08 13:18) [11]

>kaif © (08.08.03 13:08)
>И если позиция приходит со ссылкой (ссылка прямо помечена в инвойсе!) на исходный заказ, а в том такой позиции отродясь не было, то непонятно, что вставлять в такое поле (ссылка на заказ),

Ашот, я ведь объявлял о решении этой траблы. Речь идет о справочнике - номенклатуре товаров (продуктов), где каждая позиция НЕ ЗАВЯЗАНА НИ НА КАКОЙ ДОКУМЕНТ. А вот все документы (приходы, отгрузки, заказы, инвойсы и т.д.), наоборот, завязаныы именно на этот справочник ! Я вот недавно закончил проект учета давальческого сырья для шв.ф-ки. Там, конечно, своя специфика, но проблемы отличности того, что ожидалось от того, что пришло, также существуют. И были успешно преодолены благодаря подобному "номенклатурщику".

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

← →
Reindeer Moss Eater (2003-08-08 13:22) [12]

2 Reindeer Moss Eater © (08.08.03 11:26)
СЦ не подразумевает, что некое поле всегда содержит верную ссылку на существующий ключ. Это некое поле может иметь и NULL значение.

alter table MyTable add constraint tralala foreign key(myfield) references anothertable;

Вот она СЦ появилась. При этом в MyTable можно внести запись, содержащюю NULL в поле myfield.

← →
Mike B. (2003-08-08 13:23) [13]

> MsGuns © (08.08.03 13:18)
Речь, судя по всему идет о привязке конкретной номенклатурной единицы к документу(заказу).
> kaif © (07.08.03 19:20)
Все-таки, отвлекаясь от ссылочной целостности, что делается с таким товаром, так сказать "в реале"?

← →
kaif (2003-08-08 13:27) [14]

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

ОДНАКО!!!!!!!!! Если известно, что присылается "селедка соленая" со ссылкой на заказ "Васи Пупкина" №13 от такого-то числа, который эту селедку заказал, а фактически присылается "крабовая палочка идентичная селедке соленой", то что вносить в компьютер? Факт того, что согласно заказу "Васи Пупкина" №13 от такого-то числа была прислана "крабовая палочка идентичная селедке соленой"? Но ведь Вася Пупкин ничего такого не заказывал! Следовательно, "крабовая палочка идентичная селедке соленой" должна быть оприходована или выброшена (как правило) как позиция, ссылающаяся на несуществующий заказ (нарушение жесткой ссылочной целостности, сервер не позволит), либо на заказ "Всякая хрень", на который завязываются все такие дурные прецеденты. Этот "Всякая хрень" заказ, однако будет иметь дату, заказчика и т.п. и искажать отчетность за период. Поэтому это должен быть особый документ ("нуль-вектор"), имеющий особый ID=0, который обрабатывается финансовой системой отдельно и по особым правилам.
Разбивать позиции документов на две таблицы...
INVOICE_ITEMS - ANY_SHIT_IN_INVOICE_ITEMS
Это тоже выход, но для SQL корявый какой-то.

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

← →
Mike B. (2003-08-08 13:32) [15]

> kaif © (08.08.03 13:27)
Наверное все-таки вопрос надо решать не на уровне базы данных, а на уровне орагнизации бизнес-процесов, поросту говоря нужно придумать способ оформления товаров, приходящих "вне заказа". Кстати, а что происходит, напрмер если заказ выполняется не полностью (не на весь список товаров)?

← →
Sergey13 (2003-08-08 13:32) [16]

2kaif © (08.08.03 13:27)
>либо на заказ "Всякая хрень", на который завязываются все такие дурные прецеденты.

Именно для этого MsGuns © (08.08.03 11:48)предлагал
>> А сделал бы свой, "транзитный" номенклатурник, через который
>> и устанавливал бы ссылочки на конкретные товары.

← →
kaif (2003-08-08 13:38) [17]

2 Reindeer Moss Eater © (08.08.03 13:22)
alter table MyTable add constraint tralala foreign key(myfield) references anothertable;

точнее

alter table MyTable add constraint tralala foreign key(myfield) references anothertable(keyfield);

Вы не сможете вставить после такого объявления запись с
myfield is null. Вы можете объявить

alter table MyTable add constraint tralala foreign key(myfield) references anothertable(keyfield) on delete set null;

тогда после удаления записи из таблицы anothertable все записи в
MyTable, имеющие ссылку принудительно получат значение null. Однако вставить новую запись в MyTable с null тем не менее невозможно. Это эмпирический факт.

Mike B. © (08.08.03 13:23)
Все-таки, отвлекаясь от ссылочной целостности, что делается с таким товаром, так сказать "в реале"?

В реале он просто кидается на склад как "анархический приход", вне конвейера прохождения заказов. То есть обезличивается (теряет заказчика).

У меня все документы имеют ссылочную целостность на справочник товаров. Однако я еще поддерживаю ссылочную целостность между позициями и шапками документов и между позициями "связанных" документов. Почему я так делаю? Я отрабатываю некоторые технологии построения таких систем... Например важно, чтобы никто не мог случайно удалить или отредактировать товар в позиции инвойса, которая уже пришла в поставке. Это очень удобно и стройно. Ссылочная целостность у меня пронизывает буквально все, что ею можно охватить.

← →
MsGuns (2003-08-08 13:41) [18]

>Mike B. © (08.08.03 13:23)
>Речь, судя по всему идет о привязке конкретной номенклатурной единицы к документу(заказу).

Ну это само собой. Я и говорю:
1.Есть номенклатурник, содержащий список всех товаров, независимо от того, кто их делает, продает и т.п.
2.Есть ДОКУМЕНТ "Заказ" с перечнем позиций, каждая из которых ссылается на 1. У 2.есть собственный ID как позиция Заказа
3.Есть ДОКУМЕНТ "Приход" с перечнем позиций с указателями на 1.
И тоже ID собственный как позиция прихода.
4.Есть ДОКУМЕНТ "ОТГРУЗКА" с перечнем позиций с указателями на
2 и/или 3

Дальше надо объяснять ?

← →
Mike B. (2003-08-08 13:43) [19]

>kaif © (08.08.03 13:38)
По всему получается, что должны быть как бы два вида учета: учет товара пришедшего в привязке к заказу, и учет товарв пришедшего вне заказов. Или решить все организационным путем, строго лимитруя способ поступления (если такое вообще возможно)

← →
Mike B. (2003-08-08 13:46) [20]

> MsGuns © (08.08.03 13:41)
С этим согласен, только вот из постановки вопроса складывается впечатление, что способ оформления 3 в данном случае не приемлем. Или я не прав?

← →
kaif (2003-08-08 13:48) [21]

2 Mike B. © (08.08.03 13:32)
Кстати, а что происходит, напрмер если заказ выполняется не полностью (не на весь список товаров)?

А заказ часто полностью (блоком) и не выполняется. Сначала приходит одна готовая позиция, затем, может, еще несколько других. Иногда может партия в 100 шт в заказе придти как сначала 30, а потом еще 30, потом 40 шт. Поэтому и существуют отношения одни заказ - много поставок. Заказ считается закрытым, если все его позиции в конце-концов пришли в нужном количестве.

← →
Reindeer Moss Eater (2003-08-08 13:55) [22]

Вы не сможете вставить после такого объявления запись с
myfield is null. Вы можете объявить

Заинтересовался и попробовал.
Вот мой скрипт:

create table test(id integer not null primary key);
insert into test values(1);

create table anothertest(id integer not null primary key, fff integer default null);

alter table anothertest add constraint ttttt foreign key(fff) references test(id);

insert into anothertest values(1,1);
Успешно

insert into anothertest(id) values(2);
Еще раз успешный инсерт.

select count(*) from anothertest
Результат = 2

← →
kaif (2003-08-08 14:00) [23]

Представьте себе следующую картину. В поставке едет 1600 разных позиций по разным заказм. Складовщик должен сориентироваться и по распечатанной заранее (на основании нинвойсов) портянке расставить минусики в позициях, которые "посылали", но они "не доехали" по разным причинам. А в тех, что нормально доехали поставить "галочки". Эта задача решается строго. Ссылки на первичные заказы работают. Однако если пришли "не те" товары, то их приходится просто занести "анархически" в виде прихода как такового (это отдельный документ), без ссылок на заказ.
Можно было бы добавить все нехорошие позиции в портянку со ссылкой на заказ "всякая хрень" (отредактировав портянку) и менеджерам такой подход был бы весьма понятен, так как они обычно проверяют свои ошибки по финансовым суммам документов, а не попозиционно (охренеть можно проверять 1600 позиций). Они и разбиваются-то по заказам (ссылки), чтобы уменьшить путаницу.

Но это конкретная задача.

Я же спрашиваю, сталкивался ли кто-то с подобными проблемами при решении других задач и было ли оправдано (хоть где-то) применение "нулевых документов" или нет?

← →
MsGuns (2003-08-08 14:00) [24]

>Mike B. © (08.08.03 13:46)
Читаем еще раз >Mike B. © (08.08.03 13:23)

>Речь, судя по всему идет о привязке конкретной номенклатурной единицы к документу

Она (единица) по-любому будет конкретной (т.е.иметь под собой конкретный объект-запись БД). Если в отгрузке нет ссылки на Поставку (2), а только ссылка на Заказ (3), то это значит, что товара еще нет, он ожидается, но документ оформляется, хотя продукция и не отгружается (выписан счет).
Если же случай "вместо селедки отправляем крабовую палочку", то будут ссылки и на 2, и на 3, но 2 и 3 будут указывать на разный товар в номенклатурнике, что можно легко определить при первой же потребности. Или даже пометить несоответствие в самой записи отгрузки. При необходимости можно быстро "поднять" накладные с такими строчками и по обстоятельствам либо сделать замену (для счетов, к примеру), либо просто занести в спец.журнал учета (даже бумажный) для согласования с покупателем (заказчиком)

Громоздко ? Не думаю. Зато никаких суррогатных документов.

← →
kaif (2003-08-08 14:01) [25]

2 Reindeer Moss Eater © (08.08.03 13:55)
какой сервер?

← →
Reindeer Moss Eater (2003-08-08 14:03) [26]

>kaif ©
FB

← →
Reindeer Moss Eater (2003-08-08 14:06) [27]

Кстати если не добавлять создаваемому полю атрибут NULL, то при создании FK сервер создает UNIQUE KEY.
На что и идет ругань при вставке NULL (на UNIQUE KEY ругается, а не на нарушенную СЦ)

← →
Жук (2003-08-08 14:07) [28]

Наговорили, конечно, много. ИМХО самый правильный выход осуществлять связь между таблицами с помощью спец.слежебной таблицы связи. Если на приход нет заказа, то в ней ставится нулевая ссылка на справочник заказов. Таким образом "пустой" документ существует, но в справочнике его нет.

← →
kaif (2003-08-08 14:08) [29]

2 MsGuns © (08.08.03 14:00)
Возможно проблема в том, что мне не удается (или не удавалось) вставлять несуществующие ссылки (null) в поля с foriegn key.
Возможно Reindeer Moss Eater сейчас решит мою проблему. Дело именно в возможности пустых ссылок. я уже не помню, почему я в свое время пришел к тому, что в IB они не работают. Возможно, индексы ругались при Backup/Restore. В общем надо все еще раз проверить видимо. Скорее всего я неправ и пустые ссылки (NULL)возможны. Тогда разговор о "нулевых документах" отпадает сам собой. Правда я всегда избегал иметь дело с полями NULL. Потом при INNER JOIN-ах проблем не оберешься... Но может это тот случай, когда эти проблемы уместны?...

← →
kaif (2003-08-08 14:15) [30]

Reindeer Moss Eater © (08.08.03 14:06)
Кстати если не добавлять создаваемому полю атрибут NULL, то при создании FK сервер создает UNIQUE KEY.
На что и идет ругань при вставке NULL (на UNIQUE KEY ругается, а не на нарушенную СЦ)

Это очень интересно. Но я не совсем понял. Что значит не добавлять создаваемому полю атрибут NULL? Полю, создаваемому в главной таблице, на которую пойдет ссылка? Уточните, пожалуйста.
(Я работаю с Yaffil 821. Но вряд ли они отличаются в этой части.)

← →
uw (2003-08-08 14:21) [31]

>kaif © (08.08.03 14:08)
>мне не удается (или не удавалось) вставлять несуществующие ссылки (null) в поля с foriegn key.

А ведь и не удастся.

← →
kaif (2003-08-08 14:26) [32]

2 Reindeer Moss Eater © (08.08.03 14:06)

То есть решение в том, чтобы объявить
create table anothertest(id integer not null primary key, fff integer default null); ?

Я правильно понял?

А на что создается UNIQUE KEY? На fff что ли? этого же не может быть. Это же связь многие к одному (ttttt.fff -> test.id)?

← →
kaif (2003-08-08 14:29) [33]

2 uw © (08.08.03 14:21)
Что Вы имеете в виду?
У Reindeer Moss Eater © (08.08.03 13:55)
это работает на FireBird. Он только что попробовал эмпирически.

← →
Reindeer Moss Eater (2003-08-08 14:31) [34]

kaif

Речь вот о чем.
Я открыл мануал и попробовал найти способ указать явно что поле может содержат NULL значения.
Не нашел.

Если у таблицы нет FK, то поля могут содержать NULL. Это понятно.
Но стоит добавить FK для поля, как сервер создает UNIQUE KEY для этого поля. И именно он, этот уникальный ключ и не дает вставить NULL в поле.

Я извратился и объявил поле как fff integer deafult NULL.
Теперь сервер озадачен тем, что поле может содержать NULL значения, а стало быть уникальный ключ такому полю противопоказан.

Не понимаю, почему такой стандартный синтаксис
FFF integer NULL
вызывает возражения у IB

← →
uw (2003-08-08 14:35) [35]

Да, я не подумал. При неидентифицирующем отношении поле может быть с опцией NULL.

← →
Reindeer Moss Eater (2003-08-08 14:47) [36]

Ой, нет, соврал.
Тренировался на уже существующей таблице.
Нет никакого уникального ключа.
Все работает и без DEFAULT NULL.

← →
kaif (2003-08-08 14:51) [37]

2 Reindeer Moss Eater © (08.08.03 14:31)
Спасибо!! Но Вы не представляете, как вы меня озадачили... Теперь весь вопрос в том, можно ли так поступать (использовать недокументированное свойство IB), если я пишу программу на рынок. Или в данном случае можно считать это скорее упущением в документации IB и смело применять этот подход?
Меня всегда озадачивало само сообщение о попытке нарушения ключа при вставке NULL, а не о нарушении ссылочной целостности. Но я это считал особенностью системы сообщений об ошибках IB.

← →
kaif (2003-08-08 14:54) [38]

2 Reindeer Moss Eater © (08.08.03 14:47)
Ой, нет, соврал.
Тренировался на уже существующей таблице.
Нет никакого уникального ключа.
Все работает и без DEFAULT NULL.

Странно. Почему же тогда я был так уверен, что это невозможно? Дело в том, что в свое время я почти все перепробовал, чтобы выработать для себя подход в этом вопросе и уже не помню почему пришел к выводу (в результате экспериментов), что это не работает. Может это все-таки как-то связано с версиями сервера?
У Вас какой FB?

← →
Reindeer Moss Eater (2003-08-08 14:58) [39]

У меня билд не самый последний 6.2.0.794.

← →
Игорь Шевченко (2003-08-08 15:07) [40]

Для поля, объявленного как Foreign key никакого Unique index не создается. Это противоречит тому, что на одно значение primary key из reference-таблицы могут ссылаться несколько записей.
NULL является допустимым значением для поля, объявленного как foreign key, согласно стандарту SQL.

Ссылочная целостность... Найти похожие ветки