Oracle约束(Constraint)详解

共计 3155 个字符，预计需要花费 8 分钟才能阅读完成。

概述

约束是数据库用来确保数据满足业务规则的手段，不过在真正的企业开发中，除了主键约束这类具有强需求的约束，像外键约束，检查约束更多时候仅仅出现在数据库设计阶段，真实环境却很少应用，更多是放到程序逻辑中去进行处理。这也比较容易理解，约束会一定程度上较低数据库性能，有些规则直接在程序逻辑中处理就可以了，同时，也有可能在面对业务变更或是系统扩展时，数据库约束会使得处理不够方便。不过在我看来，数据库约束是保证数据准确性的最后一道防线，对于设计合理的系统，处于性能考虑数据库约束自然可有可无；不过若是面对关联关系较为复杂的系统，且对系统而言，数据的准确性完整性要高于性能要求，那么这些约束还是有必要的（否则，就会出现各种相对业务规则来说莫名其妙的脏数据，本人可是深有体会的。。）。总之，对于约束的选择无所谓合不合理，需要根据业务系统对于准确性和性能要求的侧重度来决定。

1. 键列必须必须具有唯一性，且不能为空，其实主键约束 相当于 UNIQUE+NOT NULL
2. 一个表只允许有一个主键
3. 主键所在列必须具有索引（主键的唯一约束通过索引来实现），如果不存在，将会在索引添加的时候自动创建

SQL> alter table emp add constraint emp_id_pk primary key(id);

唯一性约束（UNIQUE)

1.      对于 UNIQUE 约束来讲，索引是必须的。如果不存在，就自动创建一个（UNIQUE 的唯一性本质上是通过索引来保证的）
2.      UNIQUE 允许 null 值，UNIQUE 约束的列可存在多个 null。这是因为，Unique 唯一性通过 btree 索引来实现，而 btree 索引中不包含 null。当然，这也造成了在 where 语句中用 null 值进行过滤会造成全表扫描。

SQL> alter table emp add constraint emp_code_uq unique(code);

非空约束（NOT NULL)

非空约束作用的列也叫强制列。顾名思义，强制键列中必须有值，当然建表时候若使用 default 关键字指定了默认值，则可不输入。

添加非空约束，语法较特别

SQL> alter table emp modify ename not null;

外键约束（FOREIGN KEY）

外键约束定义在具有父子关系的子表中，外键约束使得子表中的列对应父表的主键列，用以维护数据库的完整性。不过出于性能和后期的业务系统的扩展的考虑，很多时候，外键约束仅出现在数据库的设计中，实际会放在业务程序中进行处理。外键约束注意以下几点：

1. 外键约束的子表中的列和对应父表中的列数据类型必须相同，列名可以不同
2. 对应的父表列必须存在主键约束（PRIMARY KEY）或唯一约束（UNIQUE）
3. 外键约束列允许 NULL 值，对应的行就成了孤行了

其实很多时候不使用外键，很多人认为会让删除操作比较麻烦，比如要删除父表中的某条数据，但某个子表中又有对该条数据的引用，这时就会导致删除失败。我们有两种方式来优化这种场景：

第一种方式简单粗暴，删除的时候，级联删除掉子表中的所有匹配行，在创建外键时，通过 on delete cascade 子句指定该外键列可级联删除：

SQL> alter table emp add constraint emp_deptno_fk foreign key(deptno) references dept (deptno) on delete cascade;

第二种方式，删除父表中的对应行，会将对应子表中的所有匹配行的外键约束列置为 NULL，通过 on delete set null 子句实施：

SQL> alter table emp add constraint emp_deptno_fk foreign key(deptno) references dept(deptno) on delete set null;

实际上，外键约束列和对应的父表列可以在同一张表中，常见的就是表的业务逻辑含义是一棵树，最简单的例子如下（id 为主键 id，fid 为父 id，fid 存储对 id 的引用），这种结构的表根据业务要求可通过 Oracle 的递归查询来获取这种层级关系

检查约束（CHECK)

检查约束可用来实施一些简单的规则，比如列值必须在某个范围内。检查的规则必须是一个结果为 true 或 false 的表达式，比如：

SQL> alter table emp add constraint emp_sex_ck check(sex in('男 ',' 女'));

约束状态

很多时候由于业务需要，比如我们有大量的历史数据，需要和现有数据合并，当前表存在数据库约束（如非空约束），而这些历史数据又包含违背非空约束的数据行，为了避免导入时由于违反约束而导入失败，我们通过调整约束状态来达到目的。

数据库约束有两类状态

启用 / 禁用（enable/disable）：是否对新变更的数据启用约束验证

验证 / 非验证 (validate/novalidate)：是否对表中已客观存在的数据进行约束验证

这两类四种状态从语法角度讲可以随意组合，默认是 enable validate

下面我们来看着四类组合会分别出现什么样的效果：

enable validate : 默认的约束组合状态，无法添加违反约束的数据行，数据表中也不能存在违反约束的数据行；

enable novalidate : 无法添加违反约束的数据行，但对已存在的违反约束的数据行不做验证；

disable validate : 可以添加违反约束的数据行，但对已存在的违反约束的数据行会做约束验证（从描述中可以看出来，这本来就是一种相互矛盾的约束组合，只不过是语法上支持这种组合罢了，造成的结果就是会导致 DML 失败）

disable novalidate : 可以添加违法约束的数据行，对已存在的违反约束的数据行也不做验证。

拿上面的例子来说，我们需要上传大量违反非空约束的历史数据（从业务角度讲这些数据不会造成系统功能异常），可以临时将约束状态转为 disable novalidate，以保证这些不合要求的数据导入表中

SQL> alter table emp modify constraint emp_ename_nn disable novalidate;

在数据导入完成之后，我们再将约束状态转为 enable novalidate 以确保之后添加的数据不会再违反约束

SQL> alter table emp modify constraint emp_ename_nn enable novalidate;

总结

本文介绍了数据库中的五类约束，也提到了数据库约束的四种状态组合，当你由于业务需求或是系统扩展，在一个约束严苛的系统中由于约束限制频繁操作失败的时候，不同组合的约束状态或许能给你另一种处理方案。谢谢支持。

本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-12/138331.htm