oracle外鍵--詳解____oracle

外鍵的作用：

保持資料一致性，完整性，主要目的是控制儲存在外鍵表中的資料。 使兩張表形成關聯，外鍵只能引用外表中的列的值。

例如：

a b 兩個表

a表中存有客戶號，客戶名稱

b表中存有每個客戶的訂單

有了外鍵後

你只能在確信b 表中沒有客戶x的訂單後，才可以在a表中刪除客戶x

建立外鍵的前提： 本表的列必須與外鍵類型相同(外鍵必須是外表主鍵)。

指定主鍵關鍵字： foreign key(列名)

引用外鍵關鍵字： references <外鍵表名>(外鍵列名)

事件觸發限制: on delete和on update , 可設參數cascade(跟隨外鍵改動), restrict(限制外表中的外鍵改動),set Null(設空值）,set Default（設預設值）,[預設]no action

例如：

outTable表 主鍵 id 類型 int

建立含有外鍵的表：

create table temp(

id int,

name char(20),

foreign key(id) references outTable(id) on deletecascade on update cascade);

說明：把id列 設為外鍵 參照外表outTable的id列 當外鍵的值刪除 本表中對應的列篩除 當外鍵的值改變 本表中對應的列值改變。

 cascad用法： http://blog.csdn.net/kadwf123/article/details/8067381

子表，父表的定義： 擁有外鍵的表是子表。主鍵被其它表引用的表是父表。
換句話說：因為父表的標識被很多個子表中的記錄引用，所以叫父表。
擁有外鍵關係，並且可以隨便刪除資料，不影響其它表的資料的那個表叫子表。

使用的時候誰做為誰的外鍵，主要從以下兩點考慮：
1/，刪除是如何相互影響的，刪除記錄受約束的那個是父表，不受約束的那個是子表；
2/，記錄必須先存在的是父表；

兩種用途：
1/, 最常用的一種: 減少重複資料.表A中擁有外鍵,表B的資料基本是不允許刪除的.這時選擇對 INSERT 和 UPDATE 強制關係即可.
2/，其次,是增加一個從屬表. 如果表A刪除一條記錄時，表B中也隨著刪除一條相關聯的記錄，那麼外鍵關係中，表A的主鍵是表B的外鍵。這種關係，實際上表B是表A的從屬表（即表A是父表），選擇對 INSERT 和 UPDATE 強制關係時，如果向表B中插入資料，表A中必須已經存在對應的記錄。選擇串聯刪除相關的欄位時，刪除表A中的一條記錄，就會刪除對應的表B中的一條記錄。

今天有朋友問我"外鍵的作用是什麼"

當朋友問我外鍵的作用是什麼時,我也愣了一下,平常都是在這麼用,還沒有真正的總結過,外分鍵的作用呢.下面,我總結了一下外鍵的作用: 外鍵 (FK) 是用於建立和加強兩個表資料之間的連結的一列或多列。通過將儲存表中主索引值的一列或多列添加到另一個表中，可建立兩個表之間的連結。這個列就成為第二個表的外鍵。 FOREIGN KEY 約束的主要目的是控制儲存在外鍵表中的資料，但它還可以控制對主鍵表中資料的修改。例如，如果在 publishers 表中刪除一個出版商，而這個出版商的 ID 在 titles 表中記錄書的資訊時使用了，則這兩個表之間關聯的完整性將被破壞，titles 表中該出版商的書籍因為與 publishers 表中的資料沒有連結而變得孤立了。FOREIGN KEY 約束防止這種情況的發生。如果主鍵表中資料的更改使之與外鍵表中資料的連結失效，則這種更改是不能實現的，從而確保了參考完整性。如果試圖刪除主鍵表中的行或更改主索引值，而該主索引值與另一個表的 FOREIGN KEY 約束值相關，則該操作不可實現。若要成功更改或刪除 FOREIGN KEY 約束的行，可以先在外鍵表中刪除外鍵資料或更改外鍵資料，然後將外鍵連結到不同的主鍵資料上去。 外鍵是用來控制資料庫中資料的資料完整性的 就是當你對一個表的資料進行操作 和他有關聯的一個或更多表的資料能夠同時發生改變 這就是外鍵的作用

[精] 談談外鍵

外鍵 (FK) 是用於建立和加強兩個表資料之間的連結的一列或多列。通過將儲存表中主索引值的一列或多列添加到另一個表中，可建立兩個表之間的連結。這個列就成為第二個表的外鍵。

FOREIGN KEY 約束的主要目的是控制儲存在外鍵表中的資料，但它還可以控制對主鍵表中資料的修改。例如，如果在 publishers 表中刪除一個出版商，而這個出版商的 ID 在 titles 表中記錄書的資訊時使用了，則這兩個表之間關聯的完整性將被破壞，titles 表中該出版商的書籍因為與 publishers 表中的資料沒有連結而變得孤立了。FOREIGN KEY 約束防止這種情況的發生。如果主鍵表中資料的更改使之與外鍵表中資料的連結失效，則這種更改是不能實現的，從而確保了參考完整性。如果試圖刪除主鍵表中的行或更改主索引值，而該主索引值與另一個表的 FOREIGN KEY 約束值相關，則該操作不可實現。若要成功更改或刪除 FOREIGN KEY 約束的行，可以先在外鍵表中刪除外鍵資料或更改外鍵資料，然後將外鍵連結到不同的主鍵資料上去。

外鍵是用來控制資料庫中資料的資料完整性的

就是當你對一個表的資料進行操作

和他有關聯的一個或更多表的資料能夠同時發生改變

這就是外鍵的作用

外鍵是資料庫一級的一個完整性條件約束，就是資料庫基礎理論書中所說的“參照完整性”的資料庫實現方式。

外鍵屬性當然是可以去掉的，如果你不想再用這種約束，對編程當然不會有什麼影響，但相應的錄入資料的時候就不對錄入的資料進行“參照完整性”檢查了。

例如有兩個表

A(a,b) :a為主鍵，b為外鍵（來自於B.b)

B(b,c,d) :b為主鍵

如果我把欄位b的外鍵屬性去掉，對編程沒什麼影響。

如上面，A中的b要麼為空白，要麼是在B的b中存在的值，有外鍵的時候，資料庫會自動幫你檢查A的b是否在B的b中存在。

1、外建表達的是參照完整性：這是資料固有的，與程式無關。因此，應該交給DBMS來做。

2、使用外建，簡單直觀，可以直接在資料模型中體現，無論是設計、維護等回有很大的好處，特別是對於分析現有的資料庫的好處時非常明顯的--前不久我分析了一個企業現有的資料庫，裡面的參照完整性條件約束有的是外鍵描述，有的是用觸發器實現，感覺很明顯。當然，文檔裡可能有，但是也可能不全，但是外鍵就非常明顯和直觀。

3、既然我們可以用觸發器或程式完成的這個工作（指參照完整性條件約束），DBMS已經提供了手段，為什麼我們要自己去做。而且我們做的應該說沒有RDBMS做得好。實際上，早期的RDBMS並沒有外鍵，現在都有了，我認為資料庫廠商增加這個功能是有道理的。從這個角度來說，外鍵更方便。

4、關於方便，根據我帶項目的情況來看，程式員確實有反映，主要是在調試時輸入資料麻煩：如果資料可以違反參照完整性，那麼就是說參照完整性本身就不對名譽業務衝突，此時也不應該用觸發期貨程式實現；否則，說明資料是錯誤的，根本就不應該進入資料庫。而且，這也應該是測試系統的一個內容：阻止非法資料。實際上，前景程式應該對這種提交失敗做出處理。資料是企業的而非程式的，儲程式要盡量與資料分離，反之亦然。

最後說一下,建鍵幾個原則:

1、 為關聯欄位建立外鍵。

2、 所有的鍵都必須唯一。

3、避免使用複合鍵。

4、外鍵總是關聯唯一的鍵欄位。

外鍵的作用。

外鍵是資料庫一級的一個完整性條件約束，就是資料庫基礎理論書中所說的“參照完整性”的資料庫實現方式。

外鍵屬性當然是可以去掉的，如果你不想再用這種約束，對編程當然不會有什麼影響，但相應的錄入資料的時候就不對錄入的資料進行“參照完整性”檢查了。

例如有兩個表

A(a,b) :a為主鍵，b為外鍵（來自於B.b)

B(b,c,d) :b為主鍵

如果我把欄位b的外鍵屬性去掉，對編程沒什麼影響。

如上面，A中的b要麼為空白，要麼是在B的b中存在的值，有外鍵的時候，資料庫會自動幫你檢查A的b是否在B的b中存在。

1、外建表達的是參照完整性：這是資料固有的，與程式無關。因此，應該交給DBMS來做。

2、使用外建，簡單直觀，可以直接在資料模型中體現，無論是設計、維護等回有很大的好處，特別是對於分析現有的資料庫的好處時非常明顯的--前不久我分析了一個企業現有的資料庫，裡面的參照完整性條件約束有的是外鍵描述，有的是用觸發器實現，感覺很明顯。當然，文檔裡可能有，但是也可能不全，但是外鍵就非常明顯和直觀。

3、既然我們可以用觸發器或程式完成的這個工作（指參照完整性條件約束），DBMS已經提供了手段，為什麼我們要自己去做。而且我們做的應該說沒有RDBMS做得好。實際上，早期的RDBMS並沒有外鍵，現在都有了，我認為資料庫廠商增加這個功能是有道理的。從這個角度來說，外鍵更方便。

4、關於方便，根據我帶項目的情況來看，程式員確實有反映，主要是在調試時輸入資料麻煩：如果資料可以違反參照完整性，那麼就是說參照完整性本身就不對名譽業務衝突，此時也不應該用觸發期貨程式實現；否則，說明資料是錯誤的，根本就不應該進入資料庫。而且，這也應該是測試系統的一個內容：阻止非法資料。實際上，前景程式應該對這種提交失敗做出處理。資料是企業的而非程式的，儲程式要盡量與資料分離，反之亦然。

最後說一下,建鍵幾個原則:

1、 為關聯欄位建立外鍵。

2、 所有的鍵都必須唯一。

3、避免使用複合鍵。

4、外鍵總是關聯唯一的鍵欄位。

這個文章很牛：

http://www.itpub.net/viewthread.php?tid=1313696&extra=&page=1

我的觀點是，外鍵在初始階段能加的都加上，只有迫不得已的時候才disable或drop掉。遇到效能瓶頸的時候，盡量採用其它方式調優，而不要輕易犧牲掉外鍵。有外鍵約束的時候，寫程式的確會有約束，但從直覺上說這種約束一定程度上揭示了設計或實現上不合理的地方。帶著外鍵寫出來的應用更傾向於嚴謹。產品上線之前如果確實需要通過犧牲外鍵達到效能上的最佳化，再撿相對不重要的外鍵廢棄掉，同時要把這個document下來，下次遇到資料不一致問題的時候，是個線索。兩點說明：1. 我們在做的一個項目確實是小項目。 2. 我得承認我最近三年開發都不用關係型資料庫，貌似 no sql那麼nb的key-value pair存資料，其實這三年在持久層上很多糾結。如果我說的不對，請指正。

下面引用一些有見地的想法：

× 支援外鍵的：

1. 你的程式再嚴謹也有可能出現BUG;你自己判斷不如交給資料庫判斷，它做得又快又好。
大多數人的程式沒有考慮並發問題。一旦考慮了就得手工加鎖，效率很低。
資料可能繞過你的應用程式進入資料庫。
2. 效能問題：難道你自己做就沒有開銷。
一個外鍵判斷分攤到事務層級，開銷可以忽略，使用者完全沒有察覺。
如果是大量匯入資料，可以先暫時屏蔽外鍵，事後用NOVALIDATE選項快速恢複，前提是你的資料是乾淨的。

也有人提到了如果100張表可能需要建立300個約束，導致效能太差。
我要說的仍然是，是否這300個外鍵約束都是業務必須的，如果是，沒有辦法這就是必須要加的，如果不是，那麼大可不必在所有的地方都增加外鍵。
如果在程式中僅對其中的5、6張表的10來個外鍵約束進行判斷，然後和資料庫中的300個外鍵去比較，並評價Oracle的外鍵效能太差，恐怕是有失公允的。

× 反對外鍵的：

的確外鍵在大系統中用的很少，在開發初級，設計資料庫的時候一般會加入外鍵，以保證系統設計的完整性和業務需求的完整性，也便於開發人員瞭解商務規則，在程式中加以控制，很多大系統在系統穩定後，會逐步將外鍵去掉，以保證效能，將太多的功能強加於資料庫，雖然說資料庫很強大，但是畢竟很多人不信任資料庫的能強大到什麼都能乾的地步。所以在一個大系統中外鍵見的少也不足為奇，小系統就無所謂了，用不用外鍵取決於設計人員，這樣的系統也隨處可見。

另引用一篇：

引自http://blog.csdn.net/neusoft_lkz/archive/2009/07/21/4366668.aspx

資料庫設計是否需要外鍵。這裡有兩個問題：一個是如何保證資料庫資料的完整性和一致性；二是第一條對效能的影響。
正方觀點：
1，由資料庫自身保證資料一致性，完整性，更可靠，因為程式很難100％保證資料的完整性，而用外鍵即使在資料庫伺服器當機或者出現其他問題的時候，也能夠最大限度的保證資料的一致性和完整性。
eg：資料庫和應用是一對多的關係，Ａ應用會維護他那部分資料的完整性，系統一變大時，增加了Ｂ應用，Ａ和Ｂ兩個應用也許是不同的Team Dev來做的。他們如何協調保證資料的完整性，而且一年以後如果又增加了C應用呢。 
2，有主外鍵的資料庫設計可以增加ER圖的可讀性，這點在資料庫設計時非常重要。
3，外鍵在一定程度上說明的商務邏輯，會使設計周到具體全面。
反方觀點：
1，可以用觸發器或應用程式保證資料的完整性
2，過分強調或者說使用主鍵／外鍵會平添開發難度，導致表過多等問題
3，不用外鍵時資料管理簡單，操作方便，效能高（匯入匯出等操作，在insert, update, delete 資料的時候更快）
eg:在海量的資料庫中想都不要去想外鍵，試想，一個程式每天要insert數百萬條記錄，當存在外鍵約束的時候，每次要去掃描此記錄是否合格，一般還不止一個欄位有外鍵，這樣掃描的數量是成級數的增長。我的一個程式入庫在3個小時做完，如果加上外鍵，需要28個小時。

結論：
1，在大型系統中（效能要求不高，安全要求高），使用外鍵；在大型系統中（效能要求高，安全自己控制），不用外鍵；小系統隨便，最好用外鍵。
2，用外鍵要適當，不能過分追求
3，不用外鍵而用程式控制資料一致性和完整性時，應該寫一層來保證，然後個個應用通過這個層來訪問資料庫。

資料庫中主鍵和外鍵的設計原則

http://www.cnblogs.com/tianyamoon/archive/2008/04/02/1134394.html

主鍵和外鍵是把多個表組織為一個有效關聯式資料庫的粘合劑。主鍵和外鍵的設計對物理資料庫的效能和可用性都有著決定性的影響。

必須將資料庫模式從理論上的邏輯設計轉換為實際的實體設計。而主鍵和外鍵的結構是這個設計過程的癥結所在。一旦將所設計的資料庫用於了生產環境，就很難對這些鍵進行修改，所以在開發階段就設計好主鍵和外鍵就是非常必要和值得的。

主鍵：

關聯式資料庫依賴於主鍵---它是資料庫物理模式的基石。主鍵在物理層面上只有兩個用途：

1. 惟一地標識一行。

2. 作為一個可以被外鍵有效引用的對象。

基於以上這兩個用途，下面給出了我在設計物理層面的主鍵時所遵循的一些原則：

1. 主鍵應當是