約束是數據庫用來確保數據滿足業務規則的手段，不過在真正的企業開發中，除了主鍵約束這類具有強需求的約束，像外鍵約束，檢查約束更多時候僅僅出現在數據庫設計階段，真實環境卻很少應用，更多是放到程序邏輯中去進行處理。這也比較容易理解，約束會一定程度上較低數據庫性能，有些規則直接在程序邏輯中處理就可以了，同時，也有可能在面對業務變更或是系統擴展時，數據庫約束會使得處理不夠方便。不過在我看來，數據庫約束是保證數據准確性的最後一道防線，對於設計合理的系統，處於性能考慮數據庫約束自然可有可無；不過若是面對關聯關系較為復雜的系統，且對系統而言，數據的准確性完整性要高於性能要求，那麼這些約束還是有必要的（否則，就會出現各種相對業務規則來說莫名其妙的髒數據，本人可是深有體會的。。）。總之，對於約束的選擇無所謂合不合理，需要根據業務系統對於准確性和性能要求的側重度來決定。
數據庫約束有五種：主鍵約束（PRIMARY KEY)
主鍵是定位表中單個行的方式，可唯一確定表中的某一行，關系型數據庫要求所有表都應該有主鍵，不過Oracle沒有遵循此范例要求，Oracle中的表可以沒有主鍵（這種情況不多見）。關於主鍵有幾個需要注意的點： 添加主鍵（約束的添加可在建表時創建，也可如下所示在建表後添加，一般推薦建表後添加，靈活度更高一些，建表時添加某些約束會有限制）SQL> alter table emp add constraint emp_id_pk primary key(id);
唯一性約束（UNIQUE)
唯一性約束可作用在單列或多列上，對於這些列或列組合，唯一性約束保證每一行的唯一性。 UNIQUE需要注意： 添加唯一約束SQL> alter table emp add constraint emp_code_uq unique(code);
非空約束（NOT NULL)
非空約束作用的列也叫強制列。顧名思義，強制鍵列中必須有值，當然建表時候若使用default關鍵字指定了默認值，則可不輸入。
添加非空約束，語法較特別
SQL> alter table emp modify ename not null;
外鍵約束（FOREIGN KEY）
外鍵約束定義在具有父子關系的子表中，外鍵約束使得子表中的列對應父表的主鍵列，用以維護數據庫的完整性。不過出於性能和後期的業務系統的擴展的考慮，很多時候，外鍵約束僅出現在數據庫的設計中，實際會放在業務程序中進行處理。外鍵約束注意以下幾點：
其實很多時候不使用外鍵，很多人認為會讓刪除操作比較麻煩，比如要刪除父表中的某條數據，但某個子表中又有對該條數據的引用，這時就會導致刪除失敗。我們有兩種方式來優化這種場景：
第一種方式簡單粗暴，刪除的時候，級聯刪除掉子表中的所有匹配行，在創建外鍵時，通過 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;
本文介紹了數據庫中的五類約束，也提到了數據庫約束的四種狀態組合，當你由於業務需求或是系統擴展，在一個約束嚴苛的系統中由於約束限制頻繁操作失敗的時候，不同組合的約束狀態或許能給你另一種處理方案。謝謝支持。
