我很好奇我是否可以依赖任何特定的验证NOT NULL, FOREIGN KEY, UNIQUE, CHECK
约束和BEFORE
触发器的顺序。
根据经验,我知道 MySQL 首先检查NOT NULL
,然后启动BEFORE
触发器,然后检查UNIQUE
约束。Oracle在触发器NOT NULL
之后进行检查BEFORE
(我相信 SQLServer 也会这样做,但不记得了)。标准是否说明了订单或完全取决于数据库供应商?
我很好奇我是否可以依赖任何特定的验证NOT NULL, FOREIGN KEY, UNIQUE, CHECK
约束和BEFORE
触发器的顺序。
根据经验,我知道 MySQL 首先检查NOT NULL
,然后启动BEFORE
触发器,然后检查UNIQUE
约束。Oracle在触发器NOT NULL
之后进行检查BEFORE
(我相信 SQLServer 也会这样做,但不记得了)。标准是否说明了订单或完全取决于数据库供应商?
这种特殊行为似乎是MySQL 中的一个错误,它只影响BEFORE INSERT
触发器,而BEFORE UPDATE
触发器的行为正确。
该标准(如问题评论中的链接)当然没有明确说明,但它肯定是暗示的:
对于 TECi 中的每个状态变化 SCi,j,由 SCi,j 激活的 BEFORE 触发器在其任何触发事件生效之前执行。当这些触发事件生效后,任何由 TECi 的状态变化激活的 AFTER 触发器都会被执行。
NOT NULL
错误应该是INSERT
或UPDATE
(即触发事件)的一部分。标准不需要对此进行说明。绝对没有必要先发制人地检查一组非最终更改的约束,因为您的BEFORE
触发器能够解决错误并引入新错误。
总结:这真的不取决于数据库供应商,因为在前触发器之后检查约束总是必要的。