Isso é basicamente o que chaves primárias e chaves estrangeiras e cláusulas como
ON DELETE CASCADE são para. Se não for tarde demais, você pode tentar adicionar restrições PK e FK antes de fazer qualquer exclusão; então tudo será fácil. ADICIONADO :Com base em uma discussão mais aprofundada. A consulta abaixo pode ser usada para localizar todas as tabelas descendentes de uma tabela pai. A consulta provavelmente pode ser melhorada de várias maneiras, mas pode ser um bom ponto de partida.
with f as (
select constraint_name, table_name, r_constraint_name
from user_constraints
where constraint_type = 'R'
),
p as (
select constraint_name, table_name
from user_constraints
where constraint_type = 'P'
),
j (child_table, f_key, parent_table, p_key) as (
select f.table_name, f.constraint_name, p.table_name, f.r_constraint_name
from p join f on p.constraint_name = f.r_constraint_name
union all
select 'EMPLOYEES', (select constraint_name from p
where table_name = 'EMPLOYEES'), null, null from dual
)
select level as lvl, j.*
from j
start with parent_table is null
connect by nocycle parent_table = prior child_table
order by lvl, parent_table, child_table;
A tabela "pai" neste caso é EMPLOYEES e o nome aparece duas vezes, na mesma linha. Isso pode ser transformado em uma variável de ligação, se necessário. Eu usei EMPLOYEES (observação:deve estar em letras maiúsculas porque é assim que os valores de string são armazenados nas tabelas do sistema) porque executei isso no esquema HR padrão; resultado:
LVL CHILD_TABLE F_KEY PARENT_TABLE P_KEY
----- ----------------- -------------------- ----------------- -----------------
1 EMPLOYEES EMP_EMP_ID_PK
2 DEPARTMENTS DEPT_MGR_FK EMPLOYEES EMP_EMP_ID_PK
2 JOB_HISTORY JHIST_EMP_FK EMPLOYEES EMP_EMP_ID_PK
3 JOB_HISTORY JHIST_DEPT_FK DEPARTMENTS DEPT_ID_PK
