Справочная целесность.

← →
Ihtiandr © (2003-03-21 09:51) [0]

Мажна ли как-то организовать справочную целесность в Paradox между 3-я таблицами. Одна таблица является мастером для другой.
Другая является дочерней для первой и мастером для третей.
Третяя - дочерняя для второй.

← →
Johnmen © (2003-03-21 09:53) [1]

Совсем озверел Чёрный Абдулла !

← →
Dmitry Filippov © (2003-03-21 10:05) [2]

"Справочная целесность" - это что новый термин?

← →
Ihtiandr © (2003-03-21 10:17) [3]

Свойство таблици такое слышали - "referential integrity"

← →
Соловьев © (2003-03-21 10:18) [4]

субд?

← →
Dmitry Filippov © (2003-03-21 10:24) [5]

Твой электронный переводчик врет.
Это ссылочная целостность.

← →
Dmitry Filippov © (2003-03-21 10:41) [6]

"referenced integrity"

← →
Ihtiandr © (2003-03-21 10:43) [7]

fibPlus

← →
Соловьев © (2003-03-21 10:44) [8]

это не СУБД а компоненты доступа к ... Через RK и FK...

← →
Ihtiandr © (2003-03-21 11:11) [9]

InterBase

← →
zacho © (2003-03-21 11:14) [10]

Читай Data Definition Guide: Working with tables -> Creating Tables -> Defining integrity constrains -> Enforcing referential integrity with the FOREIGN KEY

← →
Соловьев © (2003-03-21 11:18) [11]

/* Primary keys definition */ ALTER TABLE <table> ADD CONSTRAINT <pk_name> PRIMARY KEY (<field>); /* Foreign keys definition */ ALTER TABLE <table> ADD CONSTRAINT <FK_name> FOREIGN KEY (<key>) REFERENCES <parent table> (<field>) ON DELETE SET NULL ON UPDATE CASCADE;

← →
Жук © (2003-03-21 11:30) [12]

Зачем нужны вам енти проблемы с FK ?! Всё можно организовать через интерфейс али триггеры...

← →
zacho © (2003-03-21 11:34) [13]

> Жук © (21.03.03 11:30)

А книжки умные почитать, или головой подумать ? Вот посыпится у тебя база, поймешь зачем нужны FK.

← →
Жук © (2003-03-21 11:41) [14]

2 zacho ©

Типун вам на язык. :-) И что такое :
> посыпится у тебя база
?

← →
zacho © (2003-03-21 11:50) [15]

> Жук © (21.03.03 11:41)

Нарушится та самая ссылочная целостность :-) Что наиболее вероятно при "организацию через интерфейс". На триггерах действительно можно нормально организовать RI, тем более, что реально при создании FK создаются "системные" триггера. Но зачем тебе этот гемморой ? Создать индекс(иначе тормоза обеспечены) , триггер(даже несколько на каждую таблицу), причем чем для большего количества таблиц, тем больше вероятность ошибки. Гораздо проше создать FK

← →
Жук © (2003-03-21 13:22) [16]

Вам не кажется, что сохранение ссылочной целостности with help FK - нонсенс ? Я уж не говорю о reference is null, который эту самую целостность и нарушает.
Живой пример : понадобилось убрать из справочника строку, а там restrict и шо робить ?
Не хочу показаться параноиком, но все эти "10-е правила Кодда" попахивают Б.Гейтсом и иже с ним.
Сорри за оффтопик.

← →
Соловьев © (2003-03-21 13:28) [17]

> Живой пример : понадобилось убрать из справочника строку,
> а там restrict и шо робить ?

убрать из дочерной записи или присвоить им NULL. А что ты будешь делать когда у тебя будут записи из дочерней ссылаться на не сушествующие данные из родительской?
Кодд был умным мужиком. Это точно. Он был математиком. А потом программистом. Сначала надо выучить реляционную алгебру чтобы на него пинать...

← →
Johnmen © (2003-03-21 13:29) [18]

>Жук © (21.03.03 13:22)

Нет, ты неправ...:) zacho © все верно сказал...
Ты путаешь PK c FK :)

← →
Жук © (2003-03-21 13:41) [19]

Не могу найти не одного плюса в использовании FK. :-( Ссылки на преславутую целостность не выдерживают критики, а в литературе только такие объяснения. Может от меня что-нить скрывают ? :-)

← →
Johnmen © (2003-03-21 13:52) [20]

>Жук © (21.03.03 13:41)

А где конкретная критика то ???
И механизм поддержания ссылочной целостности придумали люди уж наверное не глупее нас с тобой :)

← →
Жук © (2003-03-21 14:00) [21]

Если придерживаться 10-го правила Кодда, то сохранение целостности можно реализовать 2-мя путями 1) FK
2) Триггеры. Первый путь - наиболее прямолинейный и простой, но не гибкий. Второй - более гибкий, но чреват ошибками. Я не понимаю почему вы советуете для трёх таблиц использовать FK, есть же более изящные методы.

← →
zacho © (2003-03-21 14:08) [22]

> Жук © (21.03.03 14:00)

FK и триггеры - практически одно и тоже. А никакая гибкость там и не нужна. Ну приведи хоть один практический пример "негибкости" FK

← →
Johnmen © (2003-03-21 14:08) [23]

>...есть же более изящные методы.

Например ? И в чем изящество ?

← →
Жук © (2003-03-21 14:19) [24]

> zacho © (21.03.03 14:08)
>
> FK и триггеры - практически одно и тоже.
Согласен. Но системные триггеры ворошить как-то неуютно, тогда как свой - легко.
> приведи хоть один практический пример "негибкости" FK
Негибкость - "restrict, cascade, set null", когда надо зачем-то удалить запись справочника.

> Johnmen © (21.03.03 14:08)
>
> Например ? И в чем изящество ?
Пишем триггер, который при удалении записи из справочника всем ссылкам на эту строчку присваивает номер телефона любимой девушки. Изящно ? :-)

← →
Соловьев © (2003-03-21 14:22) [25]

а зачем тебе
... ON DELETE SET NULL ON UPDATE CASCADE;

← →
Johnmen © (2003-03-21 14:23) [26]

>Жук © (21.03.03 14:19)

Как приведенный пример коррелирует с поддержанием ссылочной целостности ? :)

А где вообще автор вопроса??? Ему уже ясно?

Что такое ссылочная целостность ???

> Жук © (21.03.03 14:19)

Для этого есть CASCADE, SET NULL, SET DEFAULT
А без FK вообще нет гарантии что там какой-нибудь мусор не окажется.
Так что либо FK с DRI, либо FK+триггера, но FK все равно нужен

> Жук © (21.03.03 14:35)
> Что такое ссылочная целостность ???

Пойдет выдержка из Data Definition Guide ? :-)

The primary reason for defining foreign keys is to ensure that data integrity is maintained
when more than one table uses the same data: rows in the referencing table must always
have corresponding rows in the referenced table.

Я рад, что всем всё понятно. Правда мне не понятно зачем нужны FK, но это уже не важно. Цитата : "Ссылочная целостность - целостность отношений предок/потомок, создаваемых внешими и первичными ключами". Вывод : если у меня в базе нет внешних ключей, то ссылочная целостность там не может быть нарушена, в виду отсутствия ея, как таковой. Туше !!! :-)

> Жук © (21.03.03 14:52)

Перечитай еще раз приведенную мной выдержку. Ты ее понял как-то совсем наооборот. А там как раз написано, зачем нужны FK

Мне не нравиться, что при внесении мной изменений в БД происходят автоматические действия, инсперированные FK, или же мне сообщается, что ты не можешь это делать, ибо : "Так говорит Заратуштра".

А кто инсперировал FK ? Не ты ? Ты ! Значит несёшь ответственность !
Вобщем, хватит флеймить :) Пора прочитать нормальную книгу про идеологию построения баз данных.

Справосьная целисьнось?

Аха-ха-ха, Ихи-хи-хи, все пошел смеяться.
Китайский птися фениксь.
:-)))))

2 Жук © (21.03.03 13:41)
>Не могу найти не одного плюса в использовании FK. :-( Ссылки на >преславутую целостность не выдерживают критики, а в литературе >только такие объяснения. Может от меня что-нить скрывают ? :-)

У меня конфигурируемая бухгалтерская система, в которой конфигурирующий создает таблицы (например, новые справочники или документы). Так вот в ней все FK создаются у меня автоматически. На сегодняшний день в конфигурации под текущий заказ накопилось более 100 таблиц и немыслимое число FK. Никаких проблем с FK я не наблюдал - одни плюсы. Невозможно удалить товар, если он используется в документах. Невозможно удалить документ, на который ссылается другой документ. Это нормально. Юзеров это не пугает, наоборот, радует. FK Detail таблиц документов имеют CASCADE DELETE, что упрощает удаление документов.

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

Другой плюс - reverse engineering в любое CASE-средство, например, в Embarcadero. Я легко получаю модель всей базы со всеми связями, так как Embarcadero вылавливает эти связи, заглядывая в описания FK. В результате я получаю распечатку ERX диаграммы всей базы, потратив на это дело всего 5 минут. Руками этого просто не сделать. А документация тоже иногда хорошая вещь...

Скажу больше. Без FK у меня в базе давно бы наступил невообразимый хаос.

А если кому-то удается без FK обходиться, значит ему просто не приходилось иметь дела с сотнями таблиц и сложной бизнес-логикой.

Что же касается subj, то вопрос был про Paradox. В Paradox-е FK индексы существуют. Их можно создать прямо в Database Desktop. Я в свое время так и делал, пока не обнвружил, что в Paradox-е индексы имеют свойство рушиться.

Глюки с FK в IB6.0 имеются. В Firebird и Yaffils они исправлены. Основной глюк - невозможность создать FK на поле, которое входит, в свою очередь, в FK на третью таблицу. Но, повторяю, этот глюк устранен в Firebird и Yaffils.

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