ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBExpert [игнор отключен] [закрыт для гостей] / Ошибка при попытке создания foreign key в IBExpert
25 сообщений из 55, страница 2 из 3
  2  все
Ошибка при попытке создания foreign key в IBExpert
    #33550358
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
"kdv" <nospam@sql.ru>; сообщил/сообщила в новостях следующее:
news:2363797@sql.ru...
> 3. parentid = null позволяет построить fk с id на parentid. НО.
parentid не должен быть объявлен как not null.
> 4. при выборке корневых элементов надо писать where parent_id is
null, в то время как для всех остальных - where parentid = :param.

при выборе надо писать where coalesce(parentid,0) = :param


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
16.02.2006, 19:45
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550377
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, protector!
Ты пишешь:

protectorp> при выборе надо писать where coalesce(parentid,0) = :param
Чтоб получить PLAN NATURAL, да, именно так и нужно писать.

--
With best regards, Мимопроходящий.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
16.02.2006, 19:53
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550387
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
"kdv" <nospam@sql.ru>; сообщил/сообщила в новостях следующее:
news:2364007@sql.ru...
> то есть думать самостоятельно не хочется. Copy/Paste?
>
> что такое ON UPDATE CASCADE в FK? Это автоматическое обновление
столбца связи у деталей (в данном случае parentid) при изменении первичного
ключа мастера.
>
> Кто в здравом уме меняет значение первичного ключа у записей? Почти
никто.
>
> что такое ON DELETE CASCADE в FK? это автоматическое удаление
деталей (в данном случае записей с parentid) при удалении записи в мастере.
>
> Кто разрешает автоматически удалять детали при удалении мастера? Да
почти никто. Уж слишком опасная эта штука. Причем зачастую бессмысленная.
Допустим, мы поставим авто-удаление между таблицами заказы-клиенты. Значит,
при удалении клиента удалятся все заказы? Зашибись. То есть, отчет по
продажам мы уже правильно не сформируем.

Борьба с каскадными ключами продолжается?

Автоматическое удаление детали у мастера значительно упрощает логику, когда
мастер+детали представляют собой связанный неразрывный объект. Например
трансформатор. У него есть обмотки вводы, автотрансформаторы, и т.д которые
тоже представляют из себя сложные сущности. И если удалить мастер и не
удалить детали, то получится полная ернда. Здесь удаление мастера ВСЕГДА
должно влечь за собой удаление деталей. Так зачем мучиться и удалять 100
записей, когда можно удалить 1 и положиться на внешний ключ.
В этом плане пример с заказами некорректен. Заказ не является ЧАСТЬЮ
клиента, а только связан с ним определённым образом. Это всё равно что
сделать каскадный FK на справочник.



Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
16.02.2006, 19:57
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550398
Sexton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sexton
Участник
protector
Автоматическое удаление детали у мастера значительно упрощает логику, когда
мастер+детали представляют собой связанный неразрывный объект. Например
трансформатор. У него есть обмотки вводы, автотрансформаторы, и т.д которые
тоже представляют из себя сложные сущности. И если удалить мастер и не
удалить детали, то получится полная ернда. Здесь удаление мастера ВСЕГДА
должно влечь за собой удаление деталей. Так зачем мучиться и удалять 100
записей, когда можно удалить 1 и положиться на внешний ключ.
В этом плане пример с заказами некорректен. Заказ не является ЧАСТЬЮ
клиента, а только связан с ним определённым образом. Это всё равно что
сделать каскадный FK на справочник.

Не скажу, что не согласен, но выскажу другую точку зрения: если не делать ON UPDATE CASCADE, то FK просто не даст удалить мастера, у которого есть детали. И иногда это бывает правильнее.
...
Рейтинг: 0 / 0
16.02.2006, 20:04
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550400
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
"Мимопроходящий" <nospam@sql.ru>; сообщил/сообщила в новостях следующее:
news:2364979@sql.ru...
> Привет, protector!
> Ты пишешь:
>
> protector
> p> при выборе надо писать where coalesce(parentid,0) = :param
>
> Чтоб получить PLAN NATURAL, да, именно так и нужно писать.
>
Да ладно, описался, чего сразу придираться-то.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
16.02.2006, 20:05
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550401
Sexton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sexton
Участник
Sexton
если не делать ON UPDATE CASCADE
ON DELETE CASCADE, разумеется
...
Рейтинг: 0 / 0
16.02.2006, 20:05
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550409
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
"Sexton" <nospam@sql.ru>; сообщил/сообщила в новостях следующее:
news:2365012@sql.ru...
> Не скажу, что не согласен, но выскажу другую точку зрения: если не
делать ON UPDATE CASCADE, то FK просто не даст удалить мастера, у которого
есть детали. И иногда это бывает правильнее.

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

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
16.02.2006, 20:09
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550414
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, protector!
Ты пишешь:

protectorp> Да ладно, описался, чего сразу придираться-то. Ты мне ещё за Севастополь ответишь!..

--
With best regards, Мимопроходящий.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
16.02.2006, 20:10
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550472
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
protectorНельзя хаять каскадные ключи, якобы они и вовсе не нужны.

я попробую объяснить, почему у FK вредны опции on delete cascade и on update cascade, по пунктам. Дальше каждый волен согласиться или отказаться от конкретных аргументов.

1. on update cascade означает допустимость модификации ПК. Если ПК суррогатный, то допустимость его модификации указывают на проблемы в "консерватории". Хотя обычно on update cascade лепят "до кучи", и это так никогда и не срабатывает.

2. FK строится не от мастер-таблицы, а от детали. При этом "каскадность" работает в обратную сторону - при удалении мастера удаляются детали. По мастер-таблице никак нельзя определить, к чему приведет попытка удаления в ней записи (или изменения ПК) - к молчаливому каскадному удалению (эквивалентному удалению БЕЗ зависимых деталей, в случае обычного FK) или сообщению об ошибке.

3. каскадные FK могут привести к "зациклам". я лично наблюдал в одной БД удаление ВСЕХ записей в таблице, после удаления ОДНОЙ. Это было вызвано тем, что каскадные удаления образовали зацикл через 4-5 таблиц (сами по себе зацикливания FK - тоже нехорошо).

4. комбинирование каскадных FK и триггеров "размывают" логику программы. Например, мне попеняли на "клиенты-заказы". Хорошо, другой пример - заказы и товары в заказе. Допустим, да, удобно при удалении заказа удалить его детали. Но - заказ может иметь состояния, при которых заказ удалять нельзя. По FK такие вещи не отслеживаются. Следовательно, строим триггер вида if status... then exception. Но можно забыть, что FK каскадный, или по иным причинам отключить (деактивировать) триггер, после чего возможность удаления мастера и каскадного удаления деталей станет неконтролируемой.
тут же, насчет "мучиться удаляя 100 записей" - я думаю это описка, т.к. для удаления записей деталей, связанных с мастером, достаточно выполнить один (!) оператор delete, а не 100 операторов delete.

Пока вроде бы все. При этом не отрицаю допустимости on delete cascade, никоим образом. Предупрежден - вооружен.
...
Рейтинг: 0 / 0
16.02.2006, 21:01
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550628
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
kdv

Кто разрешает автоматически удалять детали при удалении мастера? Да почти никто. Уж слишком опасная эта штука. Причем зачастую бессмысленная.
Допустим, мы поставим авто-удаление между таблицами заказы-клиенты. Значит, при удалении клиента удалятся все заказы?

а если это не заказы-клиенты, а древовидный справочник товарных групп? пользователь создал группу "Товары народного потребления" и 30 вложенных групп. Если, позже он решил, что группа ТНП ему больше не нужна, то почему бы не облегчить ему жизнь и не дать возможность удалить одним действием как саму группу, так и все вложенные в нее.
...
Рейтинг: 0 / 0
16.02.2006, 23:26
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550770
Карабас Барабас
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Карабас Барабас
Участник
protectorмучиться и удалять 100
записей, когда можно удалить 1 и положиться на внешний ключ.Не за и не против, просто ассоциативно вспомнилось: "машина должна работать, человек - думать"
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
17.02.2006, 07:08
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33550937
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
пока не началось, добавлю:

5. on update cascade опасен в случаях, когда здоровенная таблица деталей ссылается на малочисленный справочник, и кто-то вдруг решил поменять в с правочнике идентификатор одной из записей. То есть, в результате происходит update очень большого числа записей, да еще и по столбцу с индексом, у которого немеряное число дубликатов.

Кроме того, заявления вроде "а древовидный справочник товарных групп? пользователь создал группу "Товары народного потребления" и 30 вложенных групп. Если, позже он решил, что группа ТНП ему больше не нужна, то почему бы не облегчить ему жизнь и не дать возможность удалить одним действием как саму группу, так и все вложенные в нее." меня просто умиляют, честное слово.

при таком удалении нет возможности "отменить" удаление. Обычно если пользователь чего-то удаляет, то это чего-то попадает сначала в "Корзину". А это всего-лишь изменение parent_id у самой "верхней" записи. И только потом, при очистке корзины, уже можно удалять, "по дереву". И вообще, ситуация с удалением веток дерева настолько редкая, настолько "мощная" и настолько опасная, что делать ее по on update cascade - все равно что подвесить над собой топор.
Еще одна причина так не делать - это наличие в логике сколь-нибудь минимальной проверки прав и других условий, при которых у пользователя может просто не оказаться прав удалять один из элементов (!!!) такого дерева.

Если не убедил, извините.
...
Рейтинг: 0 / 0
17.02.2006, 09:49
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33551291
Лентяй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лентяй
Участник
WWWovanИзначально все началось с необходимости изменять свойства группы(ID) вместе со всеми подгруппами. Для этого необходимо извлечь из списка все узлы некоторого поддерева.

Кстати в свое время в таких ситуациях использовал Null для того, чтобы указать, что значение свойства узла нужно брать из предка. Плюсы - меньше обновлений, а следовательно конфликтов. Кроме того можно разрулить вот такие ситуации : в узле какое-то свойство равно, скажем 100. У потомков есть узлы с этим свойством равным 200. Меняем в родительском узле свойство на 200. Автоматом у потомков его тоже меняем. Потом говорим ой, ошибка. Ставим назад в 100 и не знаем, в каком узле свойство со значением 200 было установлено по наследованию, а в каком нет...
...
Рейтинг: 0 / 0
17.02.2006, 11:29
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552320
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
"kdv" <nospam@sql.ru>; сообщил/сообщила в новостях следующее:
news:2365117@sql.ru...
> 4. комбинирование каскадных FK и триггеров "размывают" логику
программы. Например, мне попеняли на "клиенты-заказы". Хорошо, другой
пример - заказы и товары в заказе. Допустим, да, удобно при удалении заказа
удалить его детали. Но - заказ может иметь состояния, при которых заказ
удалять нельзя. По FK такие вещи не отслеживаются. Следовательно, строим
триггер вида if status... then exception. Но можно забыть, что FK каскадный,
или по иным причинам отключить (деактивировать) триггер, после чего
возможность удаления мастера и каскадного удаления деталей станет
неконтролируемой.

Почему неконтролируемой? Получается что можно УДАЛИТЬ заказ и оставить его
детали. А если нельзя, то почему удаление заказа вместе с деталями считается
ошибчной операцией. В твоём примере ничего не изменится, если оставить
просто одну таблицу заказов. Отключили триггер и удалили не то что надо. И
при чём тут FK?

> тут же, насчет "мучиться удаляя 100 записей" - я думаю это описка,
т.к. для удаления записей деталей, связанных с мастером, достаточно
выполнить один (!) оператор delete, а не 100 операторов delete.

Это если с мастером связана ОДНА таблица деталей. Например у меня в базе
есть объекты хранящиеся в нескольких десятках таблиц. (более 1000 свойств).
Для удаления нужно никак не ОДИН оператор delete? А минимум равный числу
таблиц + в каждой таблице значения первичного ключа для удаления разные так
как связаны они цепочкой. Как минимум потребуется ХП.

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
17.02.2006, 14:48
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552375
Sexton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sexton
Участник
kdv5. on update cascade опасен в случаях, когда здоровенная таблица деталей ссылается на малочисленный справочник, и кто-то вдруг решил поменять в с правочнике идентификатор одной из записей. То есть, в результате происходит update очень большого числа записей, да еще и по столбцу с индексом, у которого немеряное число дубликатов.

Поставлю интересующий меня вопрос ребром.
Ключевые поля не должны меняться - с этим полностью согласен. Но если в FK "до кучи" пихать поля не уникальные, но не пустые, с целью обновления этих полей у деталей при изменении в мастере, то on update cascade вместо обновления через триггер не имеет подводных камней? Иными словами, порочен ли on update cascade сам по себе или лишь когда его пытаются применять для обновления меняющихся (что само по себе порочно) ключевых полей?
...
Рейтинг: 0 / 0
17.02.2006, 14:59
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552421
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
SextonНо если в FK "до кучи" пихать поля не уникальныеХм... Ну вот казачок и спалился. Ты хоть пробовал это сделать?
Sextonто on update cascade не имеет подводных камней?Имеет. Один. Большой. Невозможен.
SextonИными словами, порочен ли on update cascade сам по себе или лишь когда его пытаются применять для обновления меняющихся (что само по себе порочно) ключевых полей?Ни то ни другое в чистом виде. ПК меняться не должен - с этим ты согласен. Если вдруг меняется, то в принципе никакой разницы нет, что каскадом, что триггером, лучше по-любому делать "вручную" - на клиенте или в ХП итп.
...
Рейтинг: 0 / 0
17.02.2006, 15:09
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552568
Sexton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sexton
Участник
Гаджимурадов Рустам SextonНо если в FK "до кучи" пихать поля не уникальныеХм... Ну вот казачок и спалился. Ты хоть пробовал это сделать?
Sextonто on update cascade не имеет подводных камней?Имеет. Один. Большой. Невозможен.

Пробовал, конечно, иначе бы не спрашивал. Почему невозможен? Меняю такое неключевое поле, добавленное в FK, в мастер-таблице - меняется и в детали. Наверное, мы о разном...
...
Рейтинг: 0 / 0
17.02.2006, 15:38
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552579
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Sextonнеключевое поле
Наверное, мы о разном...Наверное. И ты пожалуй плохо умеешь излагать свои мысли.
...
Рейтинг: 0 / 0
17.02.2006, 15:41
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552841
Sexton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sexton
Участник
Гаджимурадов РустамНаверное. И ты пожалуй плохо умеешь излагать свои мысли.
Угу. В форум пишу либо когда устал и мыслей в голове нет, либо когда в работе, но тогда больше думаю о работе. Вообщем, от работы надо меньше отвлекаться.

А по сути вопроса:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
CREATE TABLE TABLE1 (
  ID1 INTEGER NOT NULL,
  FIELD1 INTEGER NOT NULL
);

CREATE TABLE TABLE2 (
  ID2 INTEGER NOT NULL,
  ID1_REF INTEGER NOT NULL,
  FIELD1_COPY INTEGER NOT NULL
);

ALTER TABLE TABLE1 ADD CONSTRAINT PK_TABLE1 PRIMARY KEY (ID1);

ALTER TABLE TABLE1 ADD CONSTRAINT UNQ_TABLE1 UNIQUE (FIELD1, ID1);

ALTER TABLE TABLE2 ADD CONSTRAINT PK_TABLE2 PRIMARY KEY (ID2);

ALTER TABLE TABLE2 ADD CONSTRAINT FK_TABLE1 FOREIGN KEY (FIELD1_COPY, ID1_REF)
REFERENCES TABLE1 (FIELD1, ID1) ON UPDATE CASCADE;
Благодаря такой конструкции, в моем понимании, поле FIELD1_COPY детали всегда будет содержать копию поля FIELD1 мастера. И если FIELD1 в мастере меняется, то изменится и FIELD1_COPY. Вот я и интересуюсь, насколько порочна такая практика?
...
Рейтинг: 0 / 0
17.02.2006, 16:43
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552881
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Ну тя нафиг... Может еще о философии поговорим?
...
Рейтинг: 0 / 0
17.02.2006, 16:53
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552911
Sexton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sexton
Участник
Гаджимурадов РустамНу тя нафиг... Может еще о философии поговорим?
Ну kdv ругает on cascade update . Я на всякий случай и поинтересовался, ругает on cascade update в принципе или применительно к ключевым полям?
...
Рейтинг: 0 / 0
17.02.2006, 16:58
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552912
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
protector kdvНо можно забыть, что FK каскадный,
или по иным причинам отключить (деактивировать) триггер, после чего
возможность удаления мастера и каскадного удаления деталей станет
неконтролируемой.

Почему неконтролируемой? Получается что можно УДАЛИТЬ заказ и оставить его
детали.

вы что то путаете. По умолчанию FK НЕ дает удалить мастера если есть связанные с ним детали. То есть поведение RESTRICT.

protectorА если нельзя, то почему удаление заказа вместе с деталями считается
ошибчной операцией. В твоём примере ничего не изменится, если оставить
просто одну таблицу заказов. Отключили триггер и удалили не то что надо. И
при чём тут FK?

потому что почти в любой прикладной области все сложнее этого примитивного примера. И еще потому, что я написал что НАДО ДУМАТЬ. Я не отрицаю on delete cascade. Я говорю что он опасен при БЕЗДУМНОМ применении.

protectorесть объекты хранящиеся в нескольких десятках таблиц. (более 1000 свойств).
Для удаления нужно никак не ОДИН оператор delete? А минимум равный числу
таблиц + в каждой таблице значения первичного ключа для удаления разные так
как связаны они цепочкой. Как минимум потребуется ХП.

пора бы уже догадаться, что мне по барабану чего вы там с таблицами делаете, и как удаляете. Хоть delete from rdb$pages.
Нарушают же нормальные формы - и никто этих людей не расстреливает. Написал ты каскадное удаление - если вдруг случатся грабли, то ТЫ их огребешь. Если ты грабли предусмотрел - молодец. Я же не спорю с тобой по поводу конкретной, ТВОЕЙ, прикладной системы?
...
Рейтинг: 0 / 0
17.02.2006, 16:58
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33552950
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
SextonВот я и интересуюсь, насколько порочна такая практика?

суррогатный ПК не предполагает изменений. альтернативный ключ (unique) - допускает. Соответственно, против каскадного update на альтернативном ключе не имею ничего против. А про то, что каскадное обновление автоматически обновляет таблицу деталей, которая может содержать много одинаковых значений - просто надо помнить.

Ребята, я смотрю на эти вопросы почти что философски, пересмотрев тучу разных прикладных решений. Модель БД строится под конкретную прикладную область (в этом случае даже конкретное "дерево" можно считать именно прикладным решением). Решение для одной прикладной области не обязательно подходит для другой, вот и все. И не надо убиваться по этому поводу или спорить, отстаивая свою, конкретную, точку зрения, сформированную на одной прикладной области.
Потому что не просто смена прикладной области, а даже только усовершенствование конкретного прикладного решения может потребовать изменить эту самую точку зрения.
...
Рейтинг: 0 / 0
17.02.2006, 17:06
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33553858
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
kdv
protector
kdv
> Но можно забыть, что FK каскадный,
> или по иным причинам отключить (деактивировать) триггер,
после чего
> возможность удаления мастера и каскадного удаления
деталей станет
> неконтролируемой.

> Почему неконтролируемой? Получается что можно УДАЛИТЬ заказ и
оставить его
> детали.

>
вы что то путаете. По умолчанию FK НЕ дает удалить мастера если есть
связанные с ним детали. То есть поведение RESTRICT.

Я так понял, что НЕКОНТРОЛИРУЕМОЕ удаление связано именно с каскадным FK.
Так вот я одного не понимаю. Если записи в таблице деталей не ИМЕЮТ СМЫСЛА
без мастера, почему их нельзя удалить каскадно и автоматически. В упор не
вижу здесь никаких препядствий.

kdv
я
> А если нельзя, то почему удаление заказа вместе с деталями
считается
> ошибчной операцией. В твоём примере ничего не изменится, если
оставить
> просто одну таблицу заказов. Отключили триггер и удалили не то
что надо. И
> при чём тут FK?

> потому что почти в любой прикладной области все сложнее этого
примитивного примера. И еще потому, что я написал что НАДО ДУМАТЬ. Я не
отрицаю on delete cascade. Я говорю что он опасен при БЕЗДУМНОМ применении.

Так ведь бездумное применение не имеет к каскадным FK никакого отношения.
Бездумное применение опасно само по себе. Неужели бездумное применение
триггеров или ХП менее опаасно? В данном случае речь вообще о другом...
kdv
пора бы уже догадаться, что мне по барабану чего вы там с таблицами
делаете, и как удаляете. Хоть delete from rdb$pages.

Интересная мысль. Надо будет её обдумать.

kdv
Нарушают же нормальные формы - и никто этих людей не расстреливает.

А надо-бы!
kdv
Написал ты каскадное удаление - если вдруг случатся грабли, то ТЫ их
огребешь. Если ты грабли предусмотрел - молодец. Я же не спорю с тобой по
поводу конкретной, ТВОЕЙ, прикладной системы?

Я просто привёл пример. Конкретный пример, когда каскадно удаление удобно. И
значительно облекчает жизнь мне как разработчику. Могу другой пример
привести из другой прикладной области.


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
18.02.2006, 13:33
| Ответить | Цитировать | Написать  
Ошибка при попытке создания foreign key в IBExpert
    #33553866
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
kdv
Ребята, я смотрю на эти вопросы почти что философски, пересмотрев тучу
разных прикладных решений. Модель БД строится под конкретную прикладную
область (в этом случае даже конкретное "дерево" можно считать именно
прикладным решением). Решение для одной прикладной области не обязательно
подходит для другой, вот и все. И не надо убиваться по этому поводу или
спорить, отстаивая свою, конкретную, точку зрения, сформированную на одной
прикладной области.
Потому что не просто смена прикладной области, а даже только
усовершенствование конкретного прикладного решения может потребовать
изменить эту самую точку зрения.

Я очень уважаю твои знания и опыт, но и сам имею некоторый опыт в
проектирвании нескольких систем для различных прикладных областей на Оракуле
и Firebird. В том числе и кроссерверных. ТАк вот, IMHO предметная область к
проектированию СУБД имеет довольно опосредованное отношение, поскольку РМД
она и в африке РМД. Математческие модели разных предметных областей, в
общем-то отличаются незначительно. Набор множест отношений и операций над
ними. И общие принципы везде одинаковые. Где-то проводка, где то линия
жизни. Мат модель этих сущностей одна. Просто, если зафиксировать тезисы, то
ты утверждаешь, что

Каскадные FK опасны и их надо стараться избегать.

Я же всего-лишь утверждаю, что

Каскоадные FK очень удобны и их надо активно использовать.

Вот и всё. В остальном я с тобой полностью согласен.



Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
18.02.2006, 13:47
| Ответить | Цитировать | Написать  
25 сообщений из 55, страница 2 из 3
  2  все
Форумы / IBExpert [игнор отключен] [закрыт для гостей] / Ошибка при попытке создания foreign key в IBExpert
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=42&msg=33550387&tid=1600004]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 156ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 57ms
get tp. blocked users:
 1ms
others: 236ms
total:  495ms
созд. / загр.: 495ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]