Question

有没有办法（我可以在脚本文件的顶部添加一个命令）来了解执行时从数据库中删除了什么：

DROP TABLE MyTable CASCADE CONSTRAINTS

我现在这样做的方法是在删除myTable之前选择所有参照完整性约束：

SELECT constraint_name 
FROM user_constraints 
WHERE TABLE_NAME = 'mytable' 
AND constraint_type in ('R')

并且：

SELECT constraint_name 
FROM user_constraints 
WHERE constraint_type in ('R') 
and r_constraint_name in (select constraint_name 
                           from user_constraints
                           where constraint_type in ('P','U') 
                           and table_name='mytable')

Answer 1

我可以想到两种可能性：

如果启用了回收站，那么我假设所有放置的对象都将移动到那里。您可以查询回收站视图以查看最近删除的内容。（这可能包括不相关的对象，而这些对象恰巧在同一时间被删除了。）
激活SQL跟踪：ALTER SESSION SET SQL_TRACE = TRUE。这将导致生成一个跟踪文件，其中包含您的会话执行的所有SQL语句，包括递归SQL。您将需要访问数据库服务器才能查看跟踪文件。

Answer 2

我同意这似乎是一个遗漏，但是仔细地思考它很难看到它可能带来什么好处。

CASCADE CONSTRAINTS选项的主要用例是在重新构建模式时-通常在开发中-将DROP TABLE语句按正确顺序放置的开销过大。因为我们正在重新构建架构，所以应该还原所有外键约束，所以我们实际上不需要知道它们是什么。

这确实假定我们已正确维护了构建脚本并将其保留在源代码控制之下。如果我们不在那种幸福的境地，那么放下表并层叠外键约束是鲁re的。

类似地，如果打算删除表并将其保留，那么我们应该进行影响分析，该分析将在删除表之前确定外键。可能通过运行您在问题中遇到的那种查询：）但是您对脚本的引用表明这不是您要考虑的情况。

我们可以使用the RETURNING ... INTO syntax supported by DML statements之类的图像来描述实现该功能的Oracle。但是有问题，查询中的空白突出了这一点。 其他模式可以构建引用我们表的外键（如果我们已授予REFERENCE特权），因此查询应遍历ALL_CONSTRAINTS并返回OWNER和CONSTRAINT_NAME。这意味着假定的RETURNING ... INTO功能将需要填充两个嵌套表（或一个复杂类型的表），这可能需要很多低级的jiggery-pokery（使用技术术语），而不会带来太多好处，因为用例是如此狭窄。

看看从数据库中删除了什么drop table cascade constraints

2 个答案: