|
|
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
hi all Напоролся вчера на хрень: таблице "A" подчинена таблица "Б", а таблице "Б" - таблица "В". Потребовалось удалить данные из обеих деталек, а затем из мастера. Казалось бы, что проще: грохаем обе детали, а затем содержимое мастера. Однако, я забыл про один полезнейший триггер в таблице "В", который при удалении добавляет данные в таблицу "Б". А это означает, что нельзя удалять сначала записи из "Б", а затем из "В", надо непременно наоборот :-) В общем, показалась насущной такая задача: на основе наличия триггеров и данных по PK-FK сгенерить скрипт, который будет: 1) временно выключать все активные триггера (кроме check'ов) 2) строить правильную последовательность удалений из деталей и соотв-щих им мастеров 3) включать ранее вырубленные триггера. Понятное дело, что вариант, когда таблица по FK ссылается сама на себя, так просто не решить: надо вытряхивать ссылочные поля и генерить PSQL-код, который в цикле будет удалять записи, начиная с "самых дочерних" и заканчивая "root"-ами. А вот для ситуаций, когда таких самоссылочных таблиц нет, получилось родить следующее: Код: sql 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. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. В итоге будет выдана последовательность SQL-команд, которую надо просто скопипастить в .sql, без первой строки, ес-сно. Гляньте там у себя, кому интересно: прокатывает ли он на ваших продакшенах (ой! на копиях, конечно! :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 15:27:20 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоидтаблице "A" подчинена таблица "Б", а таблице "Б" - таблица "В" . Потребовалось удалить данные из обеих деталек, а затем из мастера. Казалось бы, что проще: грохаем обе детали, а затем содержимое мастера. Однако, я забыл про один полезнейший триггер в таблице "В", который при удалении добавляет данные в таблицу "Б". А это означает, что нельзя удалять сначала записи из "Б", а затем из "В", надо непременно наоборот :-) при чём здесь триггер, если у Вас есть деталь связки в "В"? ЗЫ ну и вопрос: а апдейт форенкеев в NULL не поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 15:39:05 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид> Напоролся вчера на хрень: таблице "A" подчинена таблица "Б", а таблице "Б" - Таблоид> таблица "В". Потребовалось удалить данные из обеих деталек, а затем из мастера. У тебя не мастер и две детали, у тебя мастер-деталь-сабдеталь, что есть большая разница. Таблоид> Однако, я забыл про один полезнейший триггер в таблице "В", Таблоид> который при удалении добавляет данные в таблицу "Б" Добавляет, а не обновляет? Посмотреть/объяснить можно? Таблоид> В общем, показалась насущной такая задача: на основе наличия Таблоид> триггеров и данных по PK-FK сгенерить скрипт, который будет: Во-первых, AFAIU, задача не насущная а выдуманная. Во-вторых, если это штатная ситуация, а не разовая, то подобное делается флагами (которые чекаются в триггерах). > Гляньте там у себя Берём грабельки, грабельки берём, недорого! (с) ? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 15:54:41 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
roadsterпри чём здесь триггер, если у Вас есть деталь связки в "В"? ЗЫ ну и вопрос: а апдейт форенкеев в NULL не поможет?Триггер в таблице "В" реагирует на ВСЕ операции по ней, в т.ч. на удаление. И делает он при операции удаления следующее: insert into "Б" values( старое_значение_из_"В" ) - т.е. "Б" - это своего рода журнал действий над "В". Но журнал этот со ссылочным полем на "А". А теперь представим себе: 1) delete from "Б"; -- грохаем журнал; тут пока всё ОК 2) delete from "В"; -- удалено 100 строк, но для каждой из них сработал триггер, добавивший в "Б" новые строки(!) 3) delete from "А"; -- получаем шваброй по лбу! Т.к. в "Б" при этом появились новые строки, см пункт "2)". Апдейт FK-полей допускается, но не везде. На таблицу-"журнал" (т.е. на "Б" навешен триггер, запрещающий апдейт в ней; допускаются только инсерты и делиты - это просто защита от "себя-дурака"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:01:11 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамВо-вторых, если это штатная ситуация, а не разовая, то подобное делается флагами (которые чекаются в триггерах).контекст имеется в виду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:01:17 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид1) delete from "Б"; -- грохаем журнал; тут пока всё ОКто есть связки мастер-деталь между Б и В нет? а говорили, что есть. а вообще это логика Вашей БД и согласно ей необходимо удалять начиная с В и не придумывать непонятно чего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:04:11 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоидна "Б" навешен триггер, запрещающий апдейт в ней; допускаются только инсерты и делитыгрантами не проще реализовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:04:56 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамДобавляет, а не обновляет? Посмотреть/объяснить можно?Только что постарался это сделать, см предыд. пост Гаджимурадов РустамВо-первых, AFAIU, задача не насущная а выдуманная.Ну как сказать... Мну приходится регулярно делать сиё. Не на продакшене, конечно, а на тестовой тряпке перед очередной заливкой данных. Но поскольку остальным до тестирования ФБ как до лампады, то, наверное, ты прав: выдумано всё и никому никогда нужно не будет :-) Гаджимурадов РустамВо-вторых, если это штатная ситуация, а не разовая, то подобное делается флагами (которые чекаются в триггерах).Эмм... поясни, плз, подробнее. Какими еще "флагами в триггерах" ? Гаджимурадов РустамБерём грабельки, грабельки берём, недорого! (с) ? ну я ж предупредил: на КОПИЯХ блин! Ну чё там, слепые все что ле ?? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:05:07 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
roadsterТаблоид1) delete from "Б"; -- грохаем журнал; тут пока всё ОКто есть связки мастер-деталь между Б и В нет? а говорили, что есть.Связки между "Б" и "В" действительно нет, попутал я, пардон. Есть связи "A" --> "Б" и "А" --> "В". Вот упрощенный DDL: Код: sql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:14:57 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
roadsterТаблоидна "Б" навешен триггер, запрещающий апдейт в ней; допускаются только инсерты и делитыгрантами не проще реализовать?Не в этом случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:15:38 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид. Речь идёт о том, чтобы не ломать башку каждый раз, с какой таблицы начинать, какие триггеры выключать/включать етц.в мире много попыток изобрести универсальный решатель, скуль не исключение. дерзайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:17:36 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
roadsterдерзайте.Спасибо за дельный совет, а то бы я не решился никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 16:30:32 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид> Только что постарался это сделать, см предыд. пост Не вникал, ибо объясняешь ты так себе, прямо скажем. Во-первых, технический (служебный) журнал это ни разу не М-Д таблица в части бизнес-логики, FK и пр. Во-вторых, журнал обычно НЕ ссылается по FK на таблицы, за которыми следит (тем паче, что их может быть несколько). В-третьих, я не вчитывался, но вроде обычные каскады (или даже один каскад) ситуацию разрулит автоматически. Если обязательно вручную делать, по какой-то дурости без каскадов, - проще тупо два раза из журнала удалять - всяко проще, чем скрипты городить, триггеры переключать. > Не на продакшене, конечно, а на тестовой тряпке > Но поскольку остальным до тестирования ФБ как до лампады Я вроде как уже не раз говорил, что на тестовой БД разумно эмулировать реальные прикладные схемы, а не выдумывать некую хрень. Фантазии у народа о-го-го, ещё и не такое придумают. У меня тоже есть две таблицы, которые друг друга триггерами защищают, но так я ж не выдаю это за норму и не по[дс]казываю всякие скрипты обхода "защиты". Но ты можешь сколько угодно дуть щёки и выдавать красное за горячее. > Эмм... поясни, плз, подробнее. Какими еще "флагами в триггерах" ? Ну, некий флаг, который проверяется в триггере и по его выставлению/значению что-то [не] делается (в твоём случае - не вставляются записи, AFAIU). Технически могут быть представлены спец.полем таблицы триггера, записью во внешней таблице или контекстной переменной. Экзотику не рассматриваем. > ну я ж предупредил: на КОПИЯХ блин! Ну чё там, слепые все что ле ?? :-) На копиях и вручную можно помудохаться, тем паче в IBE это несложно (всяко быстрее, чем скрипты гонять). Но на продакшене такое в принципе недопустимо. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 17:39:57 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамВо-первых, технический (служебный) журнал это ни разу не М-Д таблица в части бизнес-логики, FK и пр. Во-вторых, журнал обычно НЕ ссылается по FK на таблицы, за которыми следит (тем паче, что их может быть несколько).Это всё правильно ты говоришь. Но данная таблица ('moves' в вышеприведенном скрипте) является как раз тем объектом, на который будет натравливаться одиночный "служебный" аттач, выполняющий сборку оборотов по контрагентам (я реализовал схему "бесконфликтного сальдо", которую тут приводил ДС). Ну так вот: крайне не хотелось бы поиметь в этой таблице инвалидные ИДшники. А они могут быть просто из-за банальной логической ошибки. Да и вообще, должен сказать: FK много раз выручали именно по этой части, когда что-то где-то фурычило неправильно. Гаджимурадов Рустамвроде обычные каскады (или даже один каскад) ситуацию разрулит автоматически. Хм... А интересную мысль ты кинул, я серьёзно! То есть, можно будет проверить вот что: Код: plaintext 1. 2. Ну, и дальше попробовать грохнуть записи из agents и посмотреть, что там случится Гаджимурадов РустамЕсли обязательно вручную делать, по какой-то дурости без каскадов, - проще тупо два раза из журнала удалять - всяко проще, чем скрипты городить, триггеры переключать.Ну так я и напоролся на то, что записи удаляются "не все" и срабатывает ошибка по FK. И удалял их именно так: по два или три раза. И потом изабэлло как-то сиё... :-) Гаджимурадов РустамЯ вроде как уже не раз говорил, что на тестовой БД разумно эмулировать реальные прикладные схемы, а не выдумывать некую хрень. Ну так прикладную схему-то я как раз и постарался затолкать. А этот топег и запрос в его начале появился просто из-за необх-сти постоянно грохать данные и перезаливать их по-новой (ибо пробую много разных вариантов). Гаджимурадов Рустам> Эмм... поясни, плз, подробнее. Какими еще "флагами в триггерах" ? Ну, некий флаг, который проверяется в триггере и по его выставлению/значению что-то [не] делается (в твоём случае - не вставляются записи, AFAIU).Ты этот флаг должен ВЫСТАВИТЬ и затем еще не забыть УБРАТЬ. Это всё лишние телодрыгания. Человечий фактор, который когда-нить обязательно "сработает". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 18:00:43 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид> инвалидные ИДшники. А они могут быть Таблоид> просто из-за банальной логической ошибки. Если неправильно делать, все что угодно может быть. Если правильно делать, никаких инвалидных ID не будет. > Хм... А интересную мысль ты кинул, я серьёзно! Мысль. Кинул. Интересную. Ты ещё скажи, что я эти каскады изобрёл и придумал. Это азы вообще-то. Впрочем, щас прибежит Дима и начнёт как обычно голосить, что каскады - суть зло. Таблоид> Ну так я и напоролся на то, что записи удаляются "не все" Таблоид> и срабатывает ошибка по FK. И удалял их именно так: по Таблоид> два или три раза. И потом изабэлло как-то сиё... :-) И опять 25. Если что-то не получилось - надо было разбираться что именно и почему, а не изобретать лисапед с треугольными колёсами. > Ты этот флаг должен ВЫСТАВИТЬ и затем еще не забыть УБРАТЬ. > Это всё лишние телодрыгания. Человечий фактор, который когда-нить > обязательно "сработает". Это да, тяжело один раз запрос прописать, тяжело. Всяко тяжелее, чем скрипт формировать, потом его же запускать, потом триггеры все восстановить и пр. И человеческого фактора тут нет, совсем нет. И это всё безопасно - отключенный триггер бизнес-логики гораздо безопаснее забытого флага (который можно забыть только в одном варианте из трёх). Жжошь. P.S. Пятница завтра. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 18:13:31 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустамщас прибежит Дима и начнёт как обычно голосить, что каскады - суть зло.И я с ним согласен. Пришёл к выводу, что годятся они только для примитивного случае "заголовок документа - детали оного". дальше их пускать нельзя. Гаджимурадов РустамЭто да, тяжело один раз запрос прописать, тяжело.Ну так что затолкать в такой запрос-то ? Пять подряд команд вида delete from moves - просто потому, что "такой вот триггер там есть, добавляет записи втихаря, сволота" ? :-) А если не хватит пяти команд, что - шестую добавлять ? Гаджимурадов РустамВсяко тяжелее, чем скрипт формировать, потом его же запускать, потом триггеры все восстановить и пр. И человеческого фактора тут нет, совсем нет. Ты посмотрел бы на результат запроса, что ле... Там ВСЕ команды в одном флаконе: и деактивирующие триггера, и делающие удаления, и активирующие триггера. Впрочем, о чём я говорю: ты нже "не вчитывался", а значит и не запускал ничего. Гаджимурадов РустамИ это всё безопасно - отключенный триггер бизнес-логики гораздо безопаснее забытого флага (который можно забыть только в одном варианте из трёх).С какого будуга он остается отключенным, если в первой же строке скрипта выводится: set bail on ??? Ну запусти уже скрипт да посмотри, что ле... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 18:46:52 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид> И я с ним согласен. Бывает. Пройдёт со временем. > Ну так что затолкать в такой запрос-то ? В который? Если флаг таблицы - то update. Если контекстная переменная - то rdb$set_context. > Пять подряд команд вида delete from moves Каких таких пять? Если ты про повторное удаление, то всего 1 дополнительный delete. > Там ВСЕ команды в одном флаконе: и деактивирующие > триггера, и делающие удаления, и активирующие триггера. А у других не в одном флаконе, у них всё с перерывом в час? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2014, 19:15:45 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
ТаблоидНу так я и напоролся на то, что записи удаляются "не все" и срабатывает ошибка по FK. И удалял их именно так: по два или три раза. И потом изабэлло как-то сиё... :-)а почему сразу не учесть логику работы программы и не удалять в нужной последовательности? зачем дополнительно что-то искать и перепроверять? в один прекрасный день твой метод даст неприятный результат - ты удалишь то, что не надо было удалять. ТаблоидТы этот флаг должен ВЫСТАВИТЬ и затем еще не забыть УБРАТЬ. Это всё лишние телодрыгания. Человечий фактор, который когда-нить обязательно "сработает".зато очень дисциплинирует и в твоём конкретном случае защищает от бездумного удаления всего и вся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 08:15:37 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоиддеактивирующие триггерапо этому поводу ты вообще очень сильно рискуешь, потому как выключаешь из работы одно из правил бизнес-логики. в этот момент кто-то что-то может заделитить, а триггер выключен, логика нарушена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 08:18:25 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Я бы вообще сказал, что бизнес-логика в триггерах - это то еще зло. Если эти действия выполняются как-то отдельно от обычной работы, то можно завести для таких действий отдельную роль и в триггерах смотреть CURRENT_ROLE, ну и соответственно, делать или не делать что-то. По крайней мере, тогда никакие флаги не забудутся сняться и триггеры не останутся деактивированными. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 09:46:08 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
roadsterТаблоиддеактивирующие триггерапо этому поводу ты вообще очень сильно рискуешь, потому как выключаешь из работы одно из правил бизнес-логики. в этот момент кто-то что-то может заделитить, а триггер выключен, логика нарушена.Ога. Удаление данных в таблицах и деактивация триггеров - его именно днём и надо проводить. Прямо на продакшене, при сотне работающих машинорыл... ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 09:55:00 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Таблоид пишет: > Ога. Удаление данных в таблицах и деактивация триггеров - его именно днём > и надо проводить. Прямо на продакшене, при сотне работающих машинорыл... ;-) Ну если ты так уверен, что никто и никогда, ни прикаких условиях, не влезет между отключением и включением триггеров ... даже в случае атомной войны, даже в случае, если твой скрипт залипнет на пару-тройку часиков ... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 10:10:45 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Сисдба МастеркеевичНу если ты так уверен, что никто и никогда, ни прикаких условиях, не влезет между отключением и включением триггеров ... даже в случае атомной войны, даже в случае, если твой скрипт залипнет на пару-тройку часиков ...Уверен. Ибо gfix -shut single спасёт наш мир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 13:19:09 |
|
||
|
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
|
|||
|---|---|---|---|
|
#18+
Сисдба МастеркеевичЯ бы вообще сказал, что бизнес-логика в триггерах - это то еще зло.почему? ТаблоидУверен. Ибо gfix -shut single спасёт наш мир.удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 15:35:52 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38611492&tid=1563712]: |
0ms |
get settings: |
8ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
155ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
2ms |
| others: | 208ms |
| total: | 498ms |

| 0 / 0 |
