sql – INSTEAD OF触发器和CASCADE路径

前端之家收集整理的这篇文章主要介绍了sql – INSTEAD OF触发器和CASCADE路径前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
假设我在层次结构中有3个表:
TableA -> TableB -> TableC

TableC与TableB有外键关系,TableB与TableA有外键关系.

如果我删除了表A中的一个记录,它应该通过层次结构级联删除.使用ON DELETE CASCADE可以正常工作.

但是我们需要在T​​ableC上放置一个INSTEAD OF触发器.我的理解是,INSTEAD OF触发器不能放在具有删除级联的表上.取自MSDN:

For INSTEAD OF triggers,the DELETE option is not allowed on tables that have a referential relationship specifying a cascade action ON DELETE.

如果我必须在TableB-> TableC之间进行级联删除,我将需要使用INSTEAD OF触发器来强制引用完整性,然后与TableB-> TableA有相同的问题.这是一个简单的例子,但是想象一下级联路径要大得多.看起来它可以很容易地在一个漫长的瀑布路径上滚雪球.

那么处理这种情况的最佳做法是什么?

解决方法

假设您必须使用INSTEAD OF触发器,并且AFTER触发器不是一个选项,最好的方法是a)严格控制模式,以便您可以b)以常规方式脚本化INSTEAD OF触发器以实现CASCADE DELETE和任何你需要的其他操作

像以前一样创建FK约束,但是没有任何级联行为.在FK名称中,使用一些惯例来指出什么样的级联行为和自定义行为应该发生,例如:

> FK_UC_DC_Table1_Table2 – 更新级联,删除级联
> FK_UC_DN_Table1_Table3 – 更新级联,删除集合

使用任何有意义的东西,但创建FK,它们是代码生成的有用的元数据,您可以使用FK名称来记录代码生成器的指令.

然后,我会进一步,并在自己的模式中隔离这些表.它们的行为方式与其他表格不同,在测试和微调代码生成时,它们首先会更加错误.最好保留所有这些隔离,并且容易被一个普通容器识别.

专用模式还将通知任何人修改不同规则和行为的数据.

猜你在找的MsSQL相关文章