powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Каскадный ФК
55 сообщений из 55, показаны все 3 страниц
Каскадный ФК
    #39195647
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.

Есть табличка, на которую ссылаются штук 20 других. В них ФК на первую таблицу каскадные.

Возможно ли как-то отследить в каком порядке срабатывают эти самые каскады при обновлении ПК в основной таблице?


Спасибо
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195651
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv,

каскады зло. А каскады с обновлением зло в квадрате. Лучше не делать никаких предположений о порядке срабатывания, ибо его никто не гарантирует
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195652
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
опять "естественные" ключи...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195669
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисSwv,

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

почему зло то? в теле документа ПК из 5 полей. надо "перелинковать" в теле документа строку в другой документ - просто поменял в нем ссылку на другую строку шапки и все. а все прочие, зависимые от этой строки документа таблицы сами поменяли значения ФК на основную. В противном случае сложно было бы "перелинковать" строку одного документа в другой документ. а надо
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195674
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Swv!
You wrote on 18 марта 2016 г. 18:22:51:

Swv> почему зло то? в теле документа ПК из 5 полей.о! я знал...

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195675
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv,

я ещё могу понять каскадное удаление. Оно иногда требуется. Но каскадное обновление может потребоваться только для естественных ключей, а они сами по себе не сахар. А у вас там ещё и ПК аж из 5 полей. Это вообще адский ад.

Swv ... просто поменял в нем ссылку на другую строку шапки и все. а все прочие, зависимые от этой строки документа таблицы сами поменяли значения ФК на основную. В противном случае сложно было бы "перелинковать" строку одного документа в другой документ.

По моему кривой дизайн БД. Неплохо бы почитать про 3 НФ.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195678
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Симонов Денис!
You wrote on 18 марта 2016 г. 18:27:29:

Симонов Денис> По моему кривой дизайн БД. Неплохо бы почитать про 3 НФ.
и А.Тенцера про "ключ и отмычку"
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195687
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

не пойму чем не нравится такая перелинковка )


есть такая последовательность документов.

Шапка 1 - шапка 2 - шапка 3 - шапка 4 - шапка 5

при нормальном функционировании последовательно создаются все 5 документов.

но есть вариант, когда создается сразу 5 документ. а 1-4 не видны в журналах документов. по сути фэйковые они.
Перед этим отрабатывает процедурка, которая создает всю цепочку 1-4.
в первом документе есть некий атрибут-признак. и он же является частью ПК.
Который в данном случае был указан как параметр для процедуры создания цепочки документов.
Ошибся пользователь при задании параметров. указал 1, а надо было 0 в качестве этого атрибута. Можно конечно заставить его удалить документ и создать его снова с нужным параметром. А можно просто в 5 документе этот самый параметр исправить. Но исправив этот параметр , по сути получится, что вся цепочка должна приходить к документу 1 с признаком 0 а не 1. Он в системе тоже имеется.
Вот тут как раз и пригодится каскад
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195701
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
каскадная проктостоматология...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195707
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv,

Вы слышали анекдот о полностью каскадной БД, когда случайное удаление организации привело к полному схлопыванию всей базы в ноль, по зависимостям от этого корневого элемента справочника?
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195710
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий,



Ок. Признак это был введен в пк первой таблице (и идет он по всем остальным четырем) собственно для того, чтобы таблицу пятых документов можно было бы быстро отфильтровать по этому признаку не joinив все вплоть до первой таблицы.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195714
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Swv!
You wrote on 18 марта 2016 г. 18:54:39:

Swv> отфильтровать по этому признаку не joinив все вплоть до первой таблицы.
вы произвели денормализацию не начав нормализации
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195715
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery,

Согласен. Есть такая опастность. Но как же быть тогда с этим самым признаком, который проходит от первой до последней таблицы?? Можно конечно делать в триггере апдейт и тд. Но тут есть опастность просто забыть об этом в очередном документе
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195720
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий,

Может конечно что то и недопонимаю.

Но признак этот по сути важен только в первом документе.
А вот как не джойнить все при фильтре пятого документа - тут не соображу) тем более на жтом же форуме в аналогичной ситуации все дружно советовали этотсамый признак так и завернуть.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195721
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSerySwv,

Вы слышали анекдот о полностью каскадной БД, когда случайное удаление организации привело к полному схлопыванию всей базы в ноль, по зависимостям от этого корневого элемента справочника?

хороший.

но кстати поэтому и разделяют каскады на изменение и на удаление
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195726
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv, советовать тебе сейчас что-либо, не зная предметной области и поставленной задачи смысла не имеет.
есть общие принципы проектирования БД (помимо нормализации).
один из них - избегать составных ПЕРВИЧНЫХ ключей.
нужна уникальность по группе полей - создавай УНИКАЛЬНЫЙ ключ (но не первичный).
а первичный ключ обычно делают суррогатным, на генераторах, сиквенсах, автоинкрементах, UUID-ах и т.п.
на такой ключ гораздо удобнее ссылаться из FK и не нужно городить каскадные обновления.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195732
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий,

ок. будет он уникальный, а не первичный.

И на уникальный ФК у детей. Вопрос о каскаде остается актуальным )
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195784
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSeryВы слышали анекдот о полностью каскадной БД
это не анекдот. это у меня в техсаппорте было. человек жаловался, что при удалении одной записи из таблицы А удалялась пропасть данных из этой же и других нескольких связанных таблиц. Прислал копию БД, я этот ужас воочию наблюдал.
Удаляешь 1 запись, потом refresh, и ... опа!
Выяснилось, что у человека ссылки по каскадным ФК при очередном добавлении ФК замкнулись в кольцо из 4-5 таблиц. Кстати, что-то из запросов, вылавливающих циклические ссылки по ФК, попало в IBPump. Или наоборот, Борис мне такой запрос прислал (или я ему). Не помню уже.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195787
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv,

что-то школа вспомнилась, Norton Disk Edit и зацикливание папок в FAT на корень диска - чтобы учитель гад не пытался больше стирать папки с игрушками....
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195808
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Опять 25, да ещё к ночи.

Симонов Денис> каскады зло. А каскады с обновлением

С какого буя необновляемые каскады - зло?

WildSery> Вы слышали анекдот

Как будто если бы удаление в этой БД было на
триггерах, а не каскадное - стало бы легче/лучше.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195811
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да нет у меня каскадов на удаление ) есть только на обновление

а вопрос задал по той причине, что при одном из update на одной из таблиц ругнулось на нарушение FK
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195812
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

каскадное удаление нормально, но только в том случае если это тщательно обдумано. Если уж где то нужно применить каскадное удаление, то лучше делать его не глубже одного уровня. Типа шапка документа - позиции.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195821
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv> да нет у меня каскадов на удаление ) есть только на обновление

Обычно это ещу хуже. :)

> а вопрос задал по той причине, что при одном из
> update на одной из таблиц ругнулось на нарушение FK

Дык смотреть надо было, с DDL и данными.
Может у тебя циклическая зависимость.
Проблема ещё актуальна или уже разобрался?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195822
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис> каскадное удаление нормально

В таком случае тебя (и остальных, желательно)
не затруднит не называть это злом?

При чём это уже в N-ый раз, и каждый раз
одно и то же, но через полгода по новой.

> но только в том случае если это тщательно обдумано

Во-первых, нет. Во-вторых, всё остальное
тоже "если обдумано". Практически любой
оператор, даже DML нужно использовать
"только обдуманно".

> Если уж где то нужно применить каскадное удаление,
> то лучше делать его не глубже одного уровня.

Если очень кратко говоря, это бред и глупость.
Или будешь оспаривать и нужно подробнее ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195828
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

ну про каскады вообще страшилок много. Во первых порядок их срабатывания вовсе не тот что многие ожидают. Во вторых цепочка каскадов это всё равно что цепочка триггеров. Код становится совершенно не понятным и не предсказуемым. А уж если на каждой таблице участвующей в каскаде ещё и триггеры на удаление навешаны, то тут вообще пиши пропало.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195831
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис> ну про каскады вообще страшилок много

На заборах тоже пишут, не читай на ночь. :)

Симонов Денис> Во первых порядок их срабатывания вовсе
Симонов Денис> не тот что многие ожидают

Во-первых, тогда так и надо говорить, а не "зло".
Во-вторых, что ожидают многие я не знаю, но у
меня никаких претензий к порядку срабатывания
нет, что именно тебе не нравится/удивительно?

Симонов Денис> Во вторых цепочка каскадов это всё равно что цепочка триггеров

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

Симонов Денис> А уж если на каждой таблице участвующей
Симонов Денис> в каскаде ещё и триггеры на удаление навешаны

Во-первых, это несерьёзно, во-вторых, ничего
страшного при этом не будет, не "пропало".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39195886
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамПроблема ещё актуальна или уже разобрался?



видимо тут передмудрил

Код: plsql
1.
2.
ALTER TABLE TABLEZ ADD CONSTRAINT FK_TABLEZ_3 FOREIGN KEY (FIELD1_ID, FIELD2_ID, FIELD3_ID, FIELD4_ID, FLAG, FAKE) REFERENCES TABLE1 (C, FIELD2_ID, FIELD3_ID, FIELD4_ID, FLAG, FAKE) ON UPDATE CASCADE;
ALTER TABLE TABLEZ ADD CONSTRAINT FK_TABLEZ_6 FOREIGN KEY (FIELD5_ID, FIELD1_ID, FIELD3_ID, FIELD4_ID) REFERENCES TABLE1 (C, FIELD1_ID, FIELD3_ID, FIELD4_ID) ON UPDATE CASCADE;



несколько одинаковых полей были в разных ФК
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196223
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

вот только почему если в разных ФК используется одно и то же поле каскад не проходит?
вот сейчас смотрю на тело договора. там один фк на шапку. в нем есть поле признака. и второй фк на тело другого документа. там тоже используется это же поле. каскад споткнулся
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196397
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv> вот только почему если в разных ФК используется
Swv> одно и то же поле каскад не проходит?

Я не очень понял вопрос. Участие одного поля
в несколько внешних ключах не запрещено и
работает (возможно с багами). Ссылки из некольких
полей на одно поле (т.е. много деталей у мастера)
тем более не запрещено, работает годами.

Так что лучше приводи DDL. И без всяких новоязов
типа "каскад споткнулся", а точное сообщение об
ошибке и DML, который к нему привёл.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196445
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,


вот я тоже думаю, что не запрещено. но поубирав некоторые ФК на этих таблицах спотыкаться перестал
DDL слишком большой будет )

а сообщение страндартное
violation of FOREIGN KEY constraint "".
violation of FOREIGN KEY constraint "FK_BODY_1" on table "BODY".
Foreign key reference target does not exist.
Problematic key value is ("PART_ID" = 77, "MAIN_ID" = 80, "HEADER_ID" = 302, "YEAR_ID" = 3, "ORG_ID" = -1).
At trigger 'CHECK_292'
At trigger 'CHECK_290'
At trigger 'CHECK_235'.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196448
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
body это не обновляемая в данном случае таблица. до нее каскад дошел. и споткнулся
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196452
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SwvDDL слишком большой будет

DDL двух таблиц master + detail не может быть очень большим, если ты конечно не 255 столбцов в каждой создал.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196456
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сейчас нашел в одной из таблиц , которые по идее должны обновиться, не каскадный ФК. поставил у него CASCADE
и споткнулось уже на этой таблице
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196457
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

от обновляемой таблицы по набору полей зависит другая, а от нее другая... и тд. всего штук 15-20. вот по ним и идет каскад. так что думаю смысла нет смотреть на две таблицы
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196461
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swv> DDL neeoei? aieuoie aoaa? )

Как верно заметил Денис, DDL двух (или трёх)
задействованных таблиц большим быть не может.
Даже если много полей - можешь просто выкинуть
ненужные, оставив только поля PK и FK.

И DML, который приводит к ошибке, не забудь привести.
Не будет DDL+DML - вряд ли кто-то сможет помочь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196467
Ну смотри
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Swv, столько гемора из-за Swv...чтобы таблицу пятых документов можно было бы быстро отфильтровать по этому признаку не joinив все вплоть до первой таблицы.

Ну смотри. Ты фильтруешь по полю, которое у тебя продублировано в табличке нижнего уровня. Для эффективной фильтрации у тебя должен быть подходящий индекс. Иначе, если табличка большая - может получиться грустно.
...
А теперь - "с джойном". Ты фильтруешь по полю в табличке верхнего уровня. Эта табличка наверняка меньше, чем табличка "нижнего уровня". Фильтруется быстро, стало быть. А потом к остатку джойнятся только те записи, которые ты должен увидеть. Выигрыш по скорости - налицо.

Даже из-за этого есть смысл все переделать на искусственные ключи на основе целочисленной последовательности.
Выигрыш - колоссальный: не нужно каскадно обновлять данные, уменьшается размер базы, упрощается сопровождение, во мнгих случаях возрастает скорость обработки.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196470
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну смотри,

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


DDL порезал.

DDL

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
 CREATE TABLE body_table (
    C                                INTEGER NOT NULL,
    HEADER_ID                        INTEGER NOT NULL,
    YEAR_ID                          INTEGER NOT NULL,
    ORG_ID                           INTEGER NOT NULL,
    FLAG                             FLAGDOM NOT NULL,
    FAKE                             SMALLINT DEFAULT 0 NOT NULL,
    DELETED                          DOM_DELETED
);


CREATE TABLE SPECS (
    C                     INTEGER NOT NULL,
    YEAR_ID               INTEGER NOT NULL,
    body_table_ID         INTEGER NOT NULL,
    ORG_ID                INTEGER NOT NULL,
    FLAG                  FLAGDOM NOT NULL,
    FAKE                  SMALLINT NOT NULL,
    DELETED               DOM_DELETED
);


CREATE TABLE STARTP2 (
    C                     INTEGER NOT NULL,
    YEAR_ID               INTEGER NOT NULL,
    SPECS_ID              INTEGER NOT NULL,
    ORG_ID                INTEGER NOT NULL,
    FLAG                  FLAGDOM NOT NULL,
    FAKE                  SMALLINT NOT NULL,
    body_table_ID         INTEGER NOT NULL,
    DELETED               DOM_DELETED
);




/******************************************************************************/
/***                           Unique constraints                           ***/
/******************************************************************************/

ALTER TABLE body_table ADD CONSTRAINT UNQ1_body_table UNIQUE (C);
ALTER TABLE SPECS ADD CONSTRAINT UNQ1_SPECS UNIQUE (YEAR_ID, body_table_ID, ORG_ID);
ALTER TABLE STARTP2 ADD CONSTRAINT UNQ2_STARTP2 UNIQUE (C, SPECS_ID);


/******************************************************************************/
/***                              Primary keys                              ***/
/******************************************************************************/

ALTER TABLE body_table ADD CONSTRAINT PK_body_table PRIMARY KEY (C, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE);
ALTER TABLE SPECS ADD CONSTRAINT PK_SPECS PRIMARY KEY (C, body_table_ID, YEAR_ID, ORG_ID, FAKE, FLAG);
ALTER TABLE STARTP2 ADD CONSTRAINT PK_STARTP2 PRIMARY KEY (C, body_table_ID, HEADER_ID, YEAR_ID, ORG_ID, FLAG);


/******************************************************************************/
/***                              Foreign keys                              ***/
/******************************************************************************/

ALTER TABLE SPECS ADD CONSTRAINT FK_SPECS_2 FOREIGN KEY (body_table_ID, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) REFERENCES body_table (C, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) ON UPDATE CASCADE;
ALTER TABLE STARTP2 ADD CONSTRAINT FK_STARTP2_3 FOREIGN KEY (body_table_ID, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) REFERENCES body_table (C, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) ON UPDATE CASCADE;
ALTER TABLE STARTP2 ADD CONSTRAINT FK_STARTP2_5 FOREIGN KEY (SPECS_ID, body_table_ID, YEAR_ID, ORG_ID, FAKE, FLAG) REFERENCES SPECS (C, body_table_ID, YEAR_ID, ORG_ID, FAKE, FLAG) ON UPDATE CASCADE;




в данном случае спотыкается на FK_STARTP2_5. если же у него убрать каскадность, то тут уже ошибки не будет. появится на другой таблице

обновляю так

Код: plsql
1.
2.
3.
update body_table
set HEADER_ID = 30071,year_id = 3
where c=  80
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196486
Ну смотри
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Swv...но дублировал еще по той причине, что было необходимо, чтобы в тело второго документа нельзя было добавить ничего, кроме как из тела первого документа, тк первый есть основание для второго...
...

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

Насчет суррогатных кл.чей смотри сюда: http://www.informix.com.ua/articles/key/key.htm
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196540
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну смотри,

ок. есть вот такие вот таблицы

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
CREATE TABLE Z1 (
    C     INTEGER NOT NULL,
    NAME  CHAR(10)
);


CREATE TABLE Z1_1 (
    C      INTEGER NOT NULL,
    Z1_ID  INTEGER NOT NULL,
    NAME   CHAR(10)
);


CREATE TABLE Z2 (
    C        INTEGER NOT NULL,
    NAME     CHAR(10),
    BASE_ID  INTEGER NOT NULL
);


CREATE TABLE Z2_1 (
    C        INTEGER NOT NULL,
    Z2_ID    INTEGER NOT NULL,
    Z1_1_ID  INTEGER NOT NULL,
    NAME     CHAR(10)
);




/******************************************************************************/
/***                              Primary keys                              ***/
/******************************************************************************/

ALTER TABLE Z1 ADD CONSTRAINT PK_Z1 PRIMARY KEY (C);
ALTER TABLE Z1_1 ADD CONSTRAINT PK_Z1_1 PRIMARY KEY (C);
ALTER TABLE Z2 ADD CONSTRAINT PK_Z2 PRIMARY KEY (C);
ALTER TABLE Z2_1 ADD CONSTRAINT PK_Z2_1 PRIMARY KEY (C);


/******************************************************************************/
/***                              Foreign keys                              ***/
/******************************************************************************/

ALTER TABLE Z1_1 ADD CONSTRAINT FK_Z1_1_1 FOREIGN KEY (Z1_ID) REFERENCES Z1 (C);
ALTER TABLE Z2 ADD CONSTRAINT FK_Z2_1 FOREIGN KEY (BASE_ID) REFERENCES Z1 (C);
ALTER TABLE Z2_1 ADD CONSTRAINT FK_Z2_1_1 FOREIGN KEY (Z2_ID) REFERENCES Z2 (C);




z1 и z2 это два документа.
Z2.BASE_ID это базовый документ Z1. Соответственно в Z2_1 для конкретного документа не должно быть ничего, чего нет в Z1_1 соответствующего документа Z2.BASE_ID

Какое ограничение добавить? По мне так в Z2_1 надо добавить тоже base_id и создать ФК Z2_1 (Z2_id,BASE_ID) REFERENCES Z2 (C,BASE_ID). тогда добавление как должно быть не пройдет
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196554
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
могу только погрешить на зацикленные каскадные ссылочные действия ) как говорил kdv.

Есть какой нибудь запрос на выявления этих циклов?
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196555
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SwvЕсть какой нибудь запрос на выявления этих циклов?
я думал, что он у меня тут
www.ibase.ru/sysqry/

но оказывается, что нет. по идее, можно выполнить запрос 9, и просканировать его на "зацикливание".
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196580
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по стеку ошибки удалось однако узнать порядок срабатывания системных триггеров этих самых каскадов.

получилась такая картина

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
HEADER1 FOREIGN KEY (HEADER0_BODY_ID, HEADER0_ID, YEAR_ID, ORG_ID, FLAG, FAKE) REFERENCES 
HEADER0_BODY (C, HEADER0_ID, YEAR_ID, ORG_ID, FLAG, FAKE) ON UPDATE CASCADE;

	HEADER1_BODY FOREIGN KEY (HEADER1_ID, HEADER0_BODY_ID, YEAR_ID, ORG_ID, FAKE, FLAG) REFERENCES 
	HEADER1 (C, HEADER0_BODY_ID, YEAR_ID, ORG_ID, FAKE, FLAG) ON UPDATE CASCADE;

		HEADER2_BODY FOREIGN KEY (HEADER1_BODY_ID, HEADER1_ID, HEADER0_BODY_ID, YEAR_ID, ORG_ID, DELETED) REFERENCES 
		HEADER1_BODY (C, HEADER1_ID, HEADER0_BODY_ID, YEAR_ID, ORG_ID, DELETED) ON UPDATE CASCADE;



обновлялась HEADER0_BODY. а споткнулась на HEADER1_BODY
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196593
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
выполняется каскад так

HEADER0_BODY
HEADER1
HEADER2
HEADER1_BODY
HEADER2_BODY
но получается, что сначала обрабатывается HEADER1_BODY, а потом уже HEADER2. И доходит до HEADER2_BODY и обламывается.

что намудрил?

HEADER2 имеет ссылку на документ-основание HEADER1. а чтобы "залочить" HEADER2_BODY на соответствующий HEADER1_BODY в HEADER2_BODY имеется ссылка и ФК на HEADER1_BODY.
Вот тут видимо и перемудрил.
вот только как поправить с учетом того, что у второго документа есть документ документ-основание и в теле второго документа не должно быть ничего кроме как из тела документа-основания
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196613
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SwvСоответственно в Z2_1 для конкретного документа не должно быть ничего, чего нет в Z1_1 соответствующего документа Z2.BASE_IDЯННП. А то, что понял - не уверен, что понял правильно.
Более того, у тебя и с именованием объектов проблемы.

Затрудняешься объяснить - приводи таблички с данными.
Если Z11 и Z21 - это две таблицы для одной сущности
(т.е. для разных её атрибутов) - так и скажи.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196643
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

z1, z1_1 - шапка-тело ) z2 ,z2_1 аналогично
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196647
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И? Какое отношение Z21 имеет к Z11 или Z1 ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196692
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Имхо, автору следует обратиться в http://www.sql.ru/forum/db-design
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196747
tip78
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МимопроходящийSwv, советовать тебе сейчас что-либо, не зная предметной области и поставленной задачи смысла не имеет.
есть общие принципы проектирования БД (помимо нормализации).
один из них - избегать составных ПЕРВИЧНЫХ ключей.
нужна уникальность по группе полей - создавай УНИКАЛЬНЫЙ ключ (но не первичный).
а первичный ключ обычно делают суррогатным, на генераторах, сиквенсах, автоинкрементах, UUID-ах и т.п.
на такой ключ гораздо удобнее ссылаться из FK и не нужно городить каскадные обновления.

к слову, легенда гласит, что если на ПК вообще забить, mysql его сам создаст произвольно
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196781
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvэто не анекдот.Каждый анекдот - это зачастую реальное событие, гиперболизированное вплоть до абсурда, так что не вижу никаких противоречий.

Гаджимурадов РустамКак будто если бы удаление в этой БД было на
триггерах, а не каскадное - стало бы легче/лучше.Речь не о способе реализации, а о самой архитектуре.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196930
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSery> Речь не о способе реализации, а о самой архитектуре.

Это лишь игра слов, не более. Если бы "архитектура" в этой
БД была на триггерах, а не на каскадах - лучше бы не было.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39196939
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

я про это и пытался сказать. Длинные цепочки каскадов или триггеров делают БД одинаково запутанной и тяжело сопровождаемой.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39197009
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис> я про это и пытался сказать

Но сказал совсем другое.

> Длинные цепочки

Во-первых, это само по себе неверное выражение,
если ты не имеешь в виду кучу триггеров на одной
таблице, конечно. Во-вторых, по этому вопросу
много мнений и нет никакого консенсуса/правила,
так что вот так вот голословно выдавать "зло" не
стоит, наверное. Как будто "длинная цепочка"
процедур намного лучше/легче сопровождается.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39208326
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tip78к слову, легенда гласит, что если на ПК вообще забить, mysql его сам создаст произвольно

Это не легенда, а особенность www-технологий.
http://sql-info.de/mysql/database-definition.html#2_2

В конце концов изначално это был MyISAM к которому прикрутили SQL запросы, типа BDE.

PHP + MySQL 3: ты что-нибудь как-нибудь напиши, а я как-нибудь что-нибудь сделаю.
...
Рейтинг: 0 / 0
Каскадный ФК
    #39208342
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Arioch!
You wrote on 5 апреля 2016 г. 13:24:53:

Arioch> PHP + MySQL 3: ты что-нибудь как-нибудь напиши, а я как-нибудь что-нибудь сделаю.
наверное это был предвестник ORM + .NET

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Каскадный ФК
    #39208358
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий,

Прото последние стоят в болоте на плечах гuгaнтов!
...
Рейтинг: 0 / 0
55 сообщений из 55, показаны все 3 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Каскадный ФК
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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