| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Справочная целесность.
Ihtiandr © (2003-03-21 09:51:00)Мажна ли как-то организовать справочную целесность в Paradox между 3-я таблицами. Одна таблица является мастером для другой.
Другая является дочерней для первой и мастером для третей.
Третяя - дочерняя для второй.
kaif (2003-03-21 18:53:00) [1]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.
Delirium^.Tremens (2003-03-21 17:24:00) [2]Справосьная целисьнось?
Аха-ха-ха, Ихи-хи-хи, все пошел смеяться.
Китайский птися фениксь.
:-)))))
Johnmen (2003-03-21 15:30:00) [3]А кто инсперировал FK ? Не ты ? Ты ! Значит несёшь ответственность !
Вобщем, хватит флеймить :) Пора прочитать нормальную книгу про идеологию построения баз данных.
Жук (2003-03-21 15:10:00) [4]Мне не нравиться, что при внесении мной изменений в БД происходят автоматические действия, инсперированные FK, или же мне сообщается, что ты не можешь это делать, ибо : "Так говорит Заратуштра".
zacho (2003-03-21 14:55:00) [5]
> Жук © (21.03.03 14:52)
Перечитай еще раз приведенную мной выдержку. Ты ее понял как-то совсем наооборот. А там как раз написано, зачем нужны FK
Жук (2003-03-21 14:52:00) [6]Я рад, что всем всё понятно. Правда мне не понятно зачем нужны FK, но это уже не важно. Цитата : "Ссылочная целостность - целостность отношений предок/потомок, создаваемых внешими и первичными ключами". Вывод : если у меня в базе нет внешних ключей, то ссылочная целостность там не может быть нарушена, в виду отсутствия ея, как таковой. Туше !!! :-)
Johnmen (2003-03-21 14:39:00) [7]>Жук ©
Все понятно. Ты путаешь ссылочную целостность с каскадным воздействием. Это разные вещи...:)
zacho (2003-03-21 14:39:00) [8]
> Жук © (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.
zacho (2003-03-21 14:36:00) [9]
> Жук © (21.03.03 14:19)
Для этого есть CASCADE, SET NULL, SET DEFAULT
А без FK вообще нет гарантии что там какой-нибудь мусор не окажется.
Так что либо FK с DRI, либо FK+триггера, но FK все равно нужен
Жук (2003-03-21 14:35:00) [10]Что такое ссылочная целостность ???
Соловьев (2003-03-21 14:28:00) [11]А где вообще автор вопроса??? Ему уже ясно?
Johnmen (2003-03-21 14:23:00) [12]>Жук © (21.03.03 14:19)
Как приведенный пример коррелирует с поддержанием ссылочной целостности? :)
Соловьев (2003-03-21 14:22:00) [13]а зачем тебе
...ON DELETE SET NULL ON UPDATE CASCADE;
Жук (2003-03-21 14:19:00) [14]
> zacho © (21.03.03 14:08)
>
> FK и триггеры - практически одно и тоже.
Согласен. Но системные триггеры ворошить как-то неуютно, тогда как свой - легко.
> приведи хоть один практический пример "негибкости" FK
Негибкость - "restrict, cascade, set null", когда надо зачем-то удалить запись справочника.
> Johnmen © (21.03.03 14:08)
>
> Например ? И в чем изящество ?
Пишем триггер, который при удалении записи из справочника всем ссылкам на эту строчку присваивает номер телефона любимой девушки. Изящно ? :-)
Johnmen (2003-03-21 14:08:00) [15]>...есть же более изящные методы.
Например ? И в чем изящество ?
zacho (2003-03-21 14:08:00) [16]
> Жук © (21.03.03 14:00)
FK и триггеры - практически одно и тоже. А никакая гибкость там и не нужна. Ну приведи хоть один практический пример "негибкости" FK
Жук (2003-03-21 14:00:00) [17]Если придерживаться 10-го правила Кодда, то сохранение целостности можно реализовать 2-мя путями 1) FK
2) Триггеры. Первый путь - наиболее прямолинейный и простой, но не гибкий. Второй - более гибкий, но чреват ошибками. Я не понимаю почему вы советуете для трёх таблиц использовать FK, есть же более изящные методы.
Johnmen (2003-03-21 13:52:00) [18]>Жук © (21.03.03 13:41)
А где конкретная критика то ???
И механизм поддержания ссылочной целостности придумали люди уж наверное не глупее нас с тобой :)
Жук (2003-03-21 13:41:00) [19]Не могу найти не одного плюса в использовании FK. :-( Ссылки на преславутую целостность не выдерживают критики, а в литературе только такие объяснения. Может от меня что-нить скрывают ? :-)
Johnmen (2003-03-21 13:29:00) [20]>Жук © (21.03.03 13:22)
Нет, ты неправ...:) zacho © все верно сказал...
Ты путаешь PK c FK :)
| |
Страницы: 