Форум: "Базы";
Текущий архив: 2003.04.10;
Скачать: [xml.tar.bz2];
Вниз
Справочная целесность. Найти похожие ветки
← →
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)
Как приведенный пример коррелирует с поддержанием ссылочной целостности ? :)
← →
Соловьев (2003-03-21 14:28) [27]А где вообще автор вопроса??? Ему уже ясно?
← →
Жук (2003-03-21 14:35) [28]Что такое ссылочная целостность ???
← →
zacho (2003-03-21 14:36) [29]
> Жук © (21.03.03 14:19)
Для этого есть CASCADE, SET NULL, SET DEFAULT
А без FK вообще нет гарантии что там какой-нибудь мусор не окажется.
Так что либо FK с DRI, либо FK+триггера, но FK все равно нужен
← →
zacho (2003-03-21 14:39) [30]
> Жук © (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.
← →
Johnmen (2003-03-21 14:39) [31]>Жук ©
Все понятно. Ты путаешь ссылочную целостность с каскадным воздействием. Это разные вещи...:)
← →
Жук (2003-03-21 14:52) [32]Я рад, что всем всё понятно. Правда мне не понятно зачем нужны FK, но это уже не важно. Цитата : "Ссылочная целостность - целостность отношений предок/потомок, создаваемых внешими и первичными ключами". Вывод : если у меня в базе нет внешних ключей, то ссылочная целостность там не может быть нарушена, в виду отсутствия ея, как таковой. Туше !!! :-)
← →
zacho (2003-03-21 14:55) [33]
> Жук © (21.03.03 14:52)
Перечитай еще раз приведенную мной выдержку. Ты ее понял как-то совсем наооборот. А там как раз написано, зачем нужны FK
← →
Жук (2003-03-21 15:10) [34]Мне не нравиться, что при внесении мной изменений в БД происходят автоматические действия, инсперированные FK, или же мне сообщается, что ты не можешь это делать, ибо : "Так говорит Заратуштра".
← →
Johnmen (2003-03-21 15:30) [35]А кто инсперировал FK ? Не ты ? Ты ! Значит несёшь ответственность !
Вобщем, хватит флеймить :) Пора прочитать нормальную книгу про идеологию построения баз данных.
← →
Delirium^.Tremens (2003-03-21 17:24) [36]Справосьная целисьнось?
Аха-ха-ха, Ихи-хи-хи, все пошел смеяться.
Китайский птися фениксь.
:-)))))
← →
kaif (2003-03-21 18:53) [37]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.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.04.10;
Скачать: [xml.tar.bz2];
Память: 0.55 MB
Время: 0.009 c
