powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
25 сообщений из 25, страница 1 из 1
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611378
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
with recursive
c as (
    select
         rc.rdb$relation_name child_tab
        ,rc.rdb$constraint_name child_fk
        ,ru.rdb$const_name_uq parent_uk
        ,rp.rdb$relation_name parent_tab
    from rdb$relation_constraints rc
    join rdb$ref_constraints ru on
         rc.rdb$constraint_name = ru.rdb$constraint_name
         and rc.rdb$constraint_type = 'FOREIGN KEY'
    join rdb$relation_constraints rp
         on ru.rdb$const_name_uq = rp.rdb$constraint_name
    where rc.rdb$relation_name <> rp.rdb$relation_name -- prevent from select self-ref PK/FK tables!
)
,d as(
    select
        0 i
        ,child_tab
        ,child_fk
        ,parent_uk
        ,parent_tab
    from c c0
    -- отбираем таблицы, которые НЕ являются родительскими по отношению к каким-либо другим:
    where not exists( select * from c cx where cx.parent_tab= c0.child_tab ) 
    
    union all
    
    select
        d.i+1
        ,c.child_tab
        ,c.child_fk
        ,c.parent_uk
        ,c.parent_tab
    from d
    join c on d.parent_tab = c.child_tab
)
,e as(
    select
        i
        ,child_tab
        ,child_fk
        ,parent_uk
        ,parent_tab
        ,max(i)over() mi
        -- для FB 2.1, 2.5: ,(select max(i) from d) mi
    from d
)
,f as(
    -- из списка таблиц, отбираем уник. имена тех, которые НЕ являются родительскими 
    -- по отношению к каким-либо остальным:
    select distinct
        0 i
        ,child_tab
    from e where i=0

    UNION DISTINCT

    -- добавляем теперь родительские, но строго в том в порядке, в каком
    -- они формировались в рекурсии:
    select
        1
        ,child_tab
    from (select child_tab from e where i>0 order by i)

    UNION DISTINCT

    -- наконец, добавляем таблицы, НЕ являющиеся дочерними по отн. к каким-либо другим
    -- (т.е. родителей "самого высокого" уровня):
    select
        2
        ,parent_tab
    from e where i=mi
)
,t as(
    -- вытаскиваем все активные триггеры для тех таблиц, что будем чистить:
    select
        rt.rdb$trigger_name trg_name 
    from f
    join rdb$triggers rt on f.child_tab = rt.rdb$relation_name
    where rt.rdb$system_flag=0 and rt.rdb$trigger_inactive=0
)

-- составляем в нужной последовательности скрипт:
-- отключаем триггеры, чистим таблицы, включаем триггеры обратно:
select 'set bail on; commit; ' sql_expr
from rdb$database
union all
select 'alter trigger '||trim(trg_name)||' inactive;'
from t
union all
select 'delete from '||trim(child_tab)||';'
from f
union all
select 'alter trigger '||trim(trg_name)||' active;'
from t
union all
select 'set bail off; commit; '
from rdb$database;



В итоге будет выдана последовательность SQL-команд, которую надо просто скопипастить в .sql, без первой строки, ес-сно.
Гляньте там у себя, кому интересно: прокатывает ли он на ваших продакшенах (ой! на копиях, конечно! :))
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611394
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидтаблице "A" подчинена таблица "Б", а таблице "Б" - таблица "В" . Потребовалось удалить данные из обеих деталек, а затем из мастера.
Казалось бы, что проще: грохаем обе детали, а затем содержимое мастера. Однако, я забыл про один полезнейший триггер в таблице "В", который при удалении добавляет данные в таблицу "Б". А это означает, что нельзя удалять сначала записи из "Б", а затем из "В", надо непременно наоборот :-)
при чём здесь триггер, если у Вас есть деталь связки в "В"?
ЗЫ ну и вопрос: а апдейт форенкеев в NULL не поможет?
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611416
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> Напоролся вчера на хрень: таблице "A" подчинена таблица "Б", а таблице "Б" -
Таблоид> таблица "В". Потребовалось удалить данные из обеих деталек, а затем из мастера.

У тебя не мастер и две детали, у тебя мастер-деталь-сабдеталь, что есть большая разница.

Таблоид> Однако, я забыл про один полезнейший триггер в таблице "В",
Таблоид> который при удалении добавляет данные в таблицу "Б"

Добавляет, а не обновляет? Посмотреть/объяснить можно?

Таблоид> В общем, показалась насущной такая задача: на основе наличия
Таблоид> триггеров и данных по PK-FK сгенерить скрипт, который будет:

Во-первых, AFAIU, задача не насущная а выдуманная.
Во-вторых, если это штатная ситуация, а не разовая, то
подобное делается флагами (которые чекаются в триггерах).

> Гляньте там у себя

Берём грабельки, грабельки берём, недорого! (с) ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611424
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roadsterпри чём здесь триггер, если у Вас есть деталь связки в "В"?
ЗЫ ну и вопрос: а апдейт форенкеев в NULL не поможет?Триггер в таблице "В" реагирует на ВСЕ операции по ней, в т.ч. на удаление. И делает он при операции удаления следующее: insert into "Б" values( старое_значение_из_"В" ) - т.е. "Б" - это своего рода журнал действий над "В". Но журнал этот со ссылочным полем на "А".
А теперь представим себе:
1) delete from "Б"; -- грохаем журнал; тут пока всё ОК
2) delete from "В"; -- удалено 100 строк, но для каждой из них сработал триггер, добавивший в "Б" новые строки(!)
3) delete from "А"; -- получаем шваброй по лбу! Т.к. в "Б" при этом появились новые строки, см пункт "2)".

Апдейт FK-полей допускается, но не везде. На таблицу-"журнал" (т.е. на "Б" навешен триггер, запрещающий апдейт в ней; допускаются только инсерты и делиты - это просто защита от "себя-дурака").
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611425
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамВо-вторых, если это штатная ситуация, а не разовая, то
подобное делается флагами (которые чекаются в триггерах).контекст имеется в виду?
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611430
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид1) delete from "Б"; -- грохаем журнал; тут пока всё ОКто есть связки мастер-деталь между Б и В нет? а говорили, что есть.
а вообще это логика Вашей БД и согласно ей необходимо удалять начиная с В и не придумывать непонятно чего.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611435
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидна "Б" навешен триггер, запрещающий апдейт в ней; допускаются только инсерты и делитыгрантами не проще реализовать?
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611437
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамДобавляет, а не обновляет? Посмотреть/объяснить можно?Только что постарался это сделать, см предыд. пост
Гаджимурадов РустамВо-первых, AFAIU, задача не насущная а выдуманная.Ну как сказать... Мну приходится регулярно делать сиё. Не на продакшене, конечно, а на тестовой тряпке перед очередной заливкой данных.
Но поскольку остальным до тестирования ФБ как до лампады, то, наверное, ты прав: выдумано всё и никому никогда нужно не будет :-)

Гаджимурадов РустамВо-вторых, если это штатная ситуация, а не разовая, то
подобное делается флагами (которые чекаются в триггерах).Эмм... поясни, плз, подробнее. Какими еще "флагами в триггерах" ?

Гаджимурадов РустамБерём грабельки, грабельки берём, недорого! (с) ? ну я ж предупредил: на КОПИЯХ блин! Ну чё там, слепые все что ле ?? :-)
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611463
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
recreate table agents(
   id dm_ids generated by default as identity constraint pk_agents primary key using index pk_agents
  ,name dm_name unique using index agents_name_unq
  . . .
);

recreate table doc_list(
   id dm_ids constraint pk_doc_list primary key using index pk_doc_list
  ,agent_id dm_ids
  . . .
);

alter table doc_list
  add constraint fk_doc_list_agents foreign key (agent_id) references agents(id)
;

recreate table moves( -- "log" of all changes in doc_list
    id dm_ids generated by default as identity constraint pk_moves primary key using index pk_moves
   ,doc_id dm_ids 
   ,agent_id dm_ids
   . . .
);

alter table moves
   add constraint fk_moves_agents foreign key (agent_id) references agents(id)
;

create or alter trigger doc_list_aiud for doc_list
active after insert or update or delete position 0
as
  . . .
begin
    insert into moves( . . . ) values ( . . . );
end

roadsterа вообще это логика Вашей БД и согласно ей необходимо удалять начиная с В и не придумывать непонятно чего.В разных БД - разная логика. Речь идёт о том, чтобы не ломать башку каждый раз, с какой таблицы начинать, какие триггеры выключать/включать етц.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611465
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roadsterТаблоидна "Б" навешен триггер, запрещающий апдейт в ней; допускаются только инсерты и делитыгрантами не проще реализовать?Не в этом случае.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611470
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид. Речь идёт о том, чтобы не ломать башку каждый раз, с какой таблицы начинать, какие триггеры выключать/включать етц.в мире много попыток изобрести универсальный решатель, скуль не исключение.
дерзайте.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611492
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roadsterдерзайте.Спасибо за дельный совет, а то бы я не решился никогда.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611609
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> Только что постарался это сделать, см предыд. пост

Не вникал, ибо объясняешь ты так себе, прямо скажем.
Во-первых, технический (служебный) журнал это ни
разу не М-Д таблица в части бизнес-логики, FK и пр.
Во-вторых, журнал обычно НЕ ссылается по FK на
таблицы, за которыми следит (тем паче, что их может
быть несколько). В-третьих, я не вчитывался, но вроде
обычные каскады (или даже один каскад) ситуацию
разрулит автоматически. Если обязательно вручную
делать, по какой-то дурости без каскадов, - проще
тупо два раза из журнала удалять - всяко проще, чем
скрипты городить, триггеры переключать.

> Не на продакшене, конечно, а на тестовой тряпке
> Но поскольку остальным до тестирования ФБ как до лампады

Я вроде как уже не раз говорил, что на тестовой БД
разумно эмулировать реальные прикладные схемы,
а не выдумывать некую хрень. Фантазии у народа
о-го-го, ещё и не такое придумают. У меня тоже
есть две таблицы, которые друг друга триггерами
защищают, но так я ж не выдаю это за норму и не
по[дс]казываю всякие скрипты обхода "защиты".

Но ты можешь сколько угодно дуть щёки и выдавать
красное за горячее.

> Эмм... поясни, плз, подробнее. Какими еще "флагами в триггерах" ?

Ну, некий флаг, который проверяется в триггере и
по его выставлению/значению что-то [не] делается
(в твоём случае - не вставляются записи, AFAIU).
Технически могут быть представлены спец.полем
таблицы триггера, записью во внешней таблице или
контекстной переменной. Экзотику не рассматриваем.

> ну я ж предупредил: на КОПИЯХ блин! Ну чё там, слепые все что ле ?? :-)

На копиях и вручную можно помудохаться, тем паче в
IBE это несложно (всяко быстрее, чем скрипты гонять).
Но на продакшене такое в принципе недопустимо.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611650
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамВо-первых, технический (служебный) журнал это ни
разу не М-Д таблица в части бизнес-логики, FK и пр.
Во-вторых, журнал обычно НЕ ссылается по FK на
таблицы, за которыми следит (тем паче, что их может
быть несколько).Это всё правильно ты говоришь. Но данная таблица ('moves' в вышеприведенном скрипте) является как раз тем объектом, на который будет натравливаться одиночный "служебный" аттач, выполняющий сборку оборотов по контрагентам (я реализовал схему "бесконфликтного сальдо", которую тут приводил ДС). Ну так вот: крайне не хотелось бы поиметь в этой таблице инвалидные ИДшники. А они могут быть просто из-за банальной логической ошибки.
Да и вообще, должен сказать: FK много раз выручали именно по этой части, когда что-то где-то фурычило неправильно.

Гаджимурадов Рустамвроде обычные каскады (или даже один каскад) ситуацию разрулит автоматически. Хм... А интересную мысль ты кинул, я серьёзно!
То есть, можно будет проверить вот что:
Код: plaintext
1.
2.
agents (PK) --> (FK) moves on delete cascade
agents (PK) --> (FK) doc_list on delete cascade
Но при этом - внимание - в doc_list при УДАЛЕНИИ (помимо ins+upd) сидит триггерок, который делает insert into moves :-)
Ну, и дальше попробовать грохнуть записи из agents и посмотреть, что там случится

Гаджимурадов РустамЕсли обязательно вручную делать, по какой-то дурости без каскадов, - проще тупо два раза из журнала удалять - всяко проще, чем скрипты городить, триггеры переключать.Ну так я и напоролся на то, что записи удаляются "не все" и срабатывает ошибка по FK. И удалял их именно так: по два или три раза. И потом изабэлло как-то сиё... :-)

Гаджимурадов РустамЯ вроде как уже не раз говорил, что на тестовой БД разумно эмулировать реальные прикладные схемы, а не выдумывать некую хрень. Ну так прикладную схему-то я как раз и постарался затолкать. А этот топег и запрос в его начале появился просто из-за необх-сти постоянно грохать данные и перезаливать их по-новой (ибо пробую много разных вариантов).

Гаджимурадов Рустам> Эмм... поясни, плз, подробнее. Какими еще "флагами в триггерах" ?

Ну, некий флаг, который проверяется в триггере и
по его выставлению/значению что-то [не] делается
(в твоём случае - не вставляются записи, AFAIU).Ты этот флаг должен ВЫСТАВИТЬ и затем еще не забыть УБРАТЬ. Это всё лишние телодрыгания. Человечий фактор, который когда-нить обязательно "сработает".
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611671
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> инвалидные ИДшники. А они могут быть
Таблоид> просто из-за банальной логической ошибки.

Если неправильно делать, все что угодно может быть.
Если правильно делать, никаких инвалидных ID не будет.

> Хм... А интересную мысль ты кинул, я серьёзно!

Мысль. Кинул. Интересную. Ты ещё скажи, что я
эти каскады изобрёл и придумал. Это азы вообще-то.
Впрочем, щас прибежит Дима и начнёт как обычно
голосить, что каскады - суть зло.

Таблоид> Ну так я и напоролся на то, что записи удаляются "не все"
Таблоид> и срабатывает ошибка по FK. И удалял их именно так: по
Таблоид> два или три раза. И потом изабэлло как-то сиё... :-)

И опять 25. Если что-то не получилось - надо было
разбираться что именно и почему, а не изобретать
лисапед с треугольными колёсами.

> Ты этот флаг должен ВЫСТАВИТЬ и затем еще не забыть УБРАТЬ.
> Это всё лишние телодрыгания. Человечий фактор, который когда-нить
> обязательно "сработает".

Это да, тяжело один раз запрос прописать, тяжело.
Всяко тяжелее, чем скрипт формировать, потом его
же запускать, потом триггеры все восстановить и пр.
И человеческого фактора тут нет, совсем нет. И это
всё безопасно - отключенный триггер бизнес-логики
гораздо безопаснее забытого флага (который можно
забыть только в одном варианте из трёх). Жжошь.

P.S. Пятница завтра.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611704
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустамщас прибежит Дима и начнёт как обычно
голосить, что каскады - суть зло.И я с ним согласен. Пришёл к выводу, что годятся они только для примитивного случае "заголовок документа - детали оного". дальше их пускать нельзя.

Гаджимурадов РустамЭто да, тяжело один раз запрос прописать, тяжело.Ну так что затолкать в такой запрос-то ? Пять подряд команд вида delete from moves - просто потому, что "такой вот триггер там есть, добавляет записи втихаря, сволота" ? :-)
А если не хватит пяти команд, что - шестую добавлять ?

Гаджимурадов РустамВсяко тяжелее, чем скрипт формировать, потом его же запускать, потом триггеры все восстановить и пр.
И человеческого фактора тут нет, совсем нет. Ты посмотрел бы на результат запроса, что ле... Там ВСЕ команды в одном флаконе: и деактивирующие триггера, и делающие удаления, и активирующие триггера.
Впрочем, о чём я говорю: ты нже "не вчитывался", а значит и не запускал ничего.

Гаджимурадов РустамИ это всё безопасно - отключенный триггер бизнес-логики гораздо безопаснее забытого флага (который можно забыть только в одном варианте из трёх).С какого будуга он остается отключенным, если в первой же строке скрипта выводится: set bail on ??? Ну запусти уже скрипт да посмотри, что ле...
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611736
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> И я с ним согласен.

Бывает. Пройдёт со временем.

> Ну так что затолкать в такой запрос-то ?

В который? Если флаг таблицы - то update.
Если контекстная переменная - то rdb$set_context.

> Пять подряд команд вида delete from moves

Каких таких пять? Если ты про повторное
удаление, то всего 1 дополнительный delete.

> Там ВСЕ команды в одном флаконе: и деактивирующие
> триггера, и делающие удаления, и активирующие триггера.

А у других не в одном флаконе, у них всё с перерывом в час?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611971
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНу так я и напоролся на то, что записи удаляются "не все" и срабатывает ошибка по FK. И удалял их именно так: по два или три раза. И потом изабэлло как-то сиё... :-)а почему сразу не учесть логику работы программы и не удалять в нужной последовательности? зачем дополнительно что-то искать и перепроверять? в один прекрасный день твой метод даст неприятный результат - ты удалишь то, что не надо было удалять.
ТаблоидТы этот флаг должен ВЫСТАВИТЬ и затем еще не забыть УБРАТЬ. Это всё лишние телодрыгания. Человечий фактор, который когда-нить обязательно "сработает".зато очень дисциплинирует и в твоём конкретном случае защищает от бездумного удаления всего и вся.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38611973
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоиддеактивирующие триггерапо этому поводу ты вообще очень сильно рискуешь, потому как выключаешь из работы одно из правил бизнес-логики. в этот момент кто-то что-то может заделитить, а триггер выключен, логика нарушена.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38612017
Сисдба Мастеркеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы вообще сказал, что бизнес-логика в триггерах - это то еще зло.

Если эти действия выполняются как-то отдельно от обычной работы, то можно завести для таких действий отдельную роль и в триггерах смотреть CURRENT_ROLE, ну и соответственно, делать или не делать что-то. По крайней мере, тогда никакие флаги не забудутся сняться и триггеры не останутся деактивированными.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38612028
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roadsterТаблоиддеактивирующие триггерапо этому поводу ты вообще очень сильно рискуешь, потому как выключаешь из работы одно из правил бизнес-логики. в этот момент кто-то что-то может заделитить, а триггер выключен, логика нарушена.Ога. Удаление данных в таблицах и деактивация триггеров - его именно днём и надо проводить. Прямо на продакшене, при сотне работающих машинорыл... ;-)
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38612052
Сисдба Мастеркеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид пишет:

> Ога. Удаление данных в таблицах и деактивация триггеров - его именно днём
> и надо проводить. Прямо на продакшене, при сотне работающих машинорыл... ;-)

Ну если ты так уверен, что никто и никогда, ни прикаких условиях, не влезет между отключением и включением триггеров ... даже в случае атомной войны, даже в случае, если твой скрипт залипнет на пару-тройку часиков ...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38612257
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сисдба МастеркеевичНу если ты так уверен, что никто и никогда, ни прикаких условиях, не влезет между отключением и включением триггеров ... даже в случае атомной войны, даже в случае, если твой скрипт залипнет на пару-тройку часиков ...Уверен. Ибо gfix -shut single спасёт наш мир.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38612505
Фотография roadster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сисдба МастеркеевичЯ бы вообще сказал, что бизнес-логика в триггерах - это то еще зло.почему?
ТаблоидУверен. Ибо gfix -shut single спасёт наш мир.удачи.
...
Рейтинг: 0 / 0
Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
    #38612532
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roadsterудачи.И тебе счастливого пути.
...
Рейтинг: 0 / 0
25 сообщений из 25, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Удаление данных из таблиц, связанных по PK-FK: запрос, генерирующий соотв. SQL-скрипт
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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