Immediate Constraints
--------------------------------
这种约束一般就是我们默认的约束模式,完整性约束一般是在SQL语句得到处理之后才会立即检查,那么为什么要在SQL语句执行之后检查,而不是在SQL语句执行期间呢?
主要就是为了解决的"temp inconsistent"的问题。
来看一个例子
SQL> create table t
2 (x int unique);
表已创建。
SQL> insert into t values (1);
已创建 1 行。
SQL> insert into t values (2);
已创建 1 行。
SQL> update t set x = x + 1;
已更新2行。
由于我们的SQL语句的处理会按照行的顺序来进行,在处理更新完第一行的时候,值已经又1变为了2,和第二行的2正好有了unquie约束的冲突。这样update就不会顺利进行了,由此我们可以判断,在immediate模式下呢,完整性约束的检查是在SQL语句执行之后开始的
Deferrable Constraints
-------------------------------
这类限制型约束主要就是为了延迟约束的检查,可以想象一个cascade的update操作,一般来将,因为有了主外键的约束,对于父表中已别子表做为外键而引用的主键的更新一般,是会被约束检查为违反规则的情况。那么通过如下的测试我们可以实现分阶段更新,这样的主键:
SQL> create table p
2 (pk int primary key);
表已创建。
SQL> create table c
2 (fk constraint c_fk references p(pk)
3 deferrable
4 initially immediate);
表已创建。
SQL> insert into p values (1);
已创建 1 行。
SQL> insert into c values (1);
已创建 1 行。
SQL> update p set pk=2;
update p set pk=2
*
ERROR 位于第 1 行:
ORA-02292: 违反完整约束条件 (SYS.C_FK) - 已找到子记录日志
SQL> set constraint c_fk deferred;
约束条件已设置。
SQL> update p set pk=2;
已更新 1 行。
SQL> set constraint c_fk immediate;
SET constraint c_fk immediate
*
ERROR 位于第 1 行:
ORA-02291: 违反完整约束条件 (SYS.C_FK) - 未找到父项关键字
SQL> commit;
commit
*
ERROR 位于第 1 行:
ORA-02091: 事务处理已重算
ORA-02292: 违反完整约束条件 (SYS.C_FK) - 已找到子记录日志。
而如果之前,我们在提交之前继续更新c表将其中的fk的value设置为pk修改后的value。commit就会成功。否则还是会失败。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12361284/viewspace-15517/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12361284/viewspace-15517/