主鍵和外鍵是把多個表組織為一個有效的關係資料庫的黏合劑。主鍵和外鍵的設計對實體資料庫的效能和可用性都有決定性的影響。
必須將資料庫模式從理論上的邏輯設計轉換為實際的物理設計。而主鍵和外鍵的結構就是這個設計過程的癥結所在。一旦將所設計的資料庫用於了生產環境，就很難對這些鍵進行修改，所以在開發階段就設計好主鍵和外鍵就是非常必要且值得的。
主鍵：
關係資料庫依賴主鍵---它是資料庫物理模式的基石。主鍵在物理層面上只有兩個用途：
1. 惟一地標識一行。
2. 作為一個可以被外鍵有效引用的物件。
基於以上這兩個用途，以下給出了我在設計物理層面的主鍵時所遵循的一些原則：
1. 主鍵應是對使用者沒有意義的。如果使用者看到了一個表示多對多關係的連接表中的數據，並抱怨它沒有什麼用處，那就證明它的主鍵設計地很好。
2. 主鍵應該是單列的，以便提高連接和篩選操作的效率。
註：使用複合鍵的人通常有兩個理由為自己開脫，而這兩個理由都是錯的。其一是主鍵應具有實際意義，然而，讓主鍵具有意義只不過是給人為地破壞資料庫提供了方便。其二是利用這種方法可以在描述多對多關係的連接表中使用兩個外部鍵來作為主鍵，我也反對這種做法，理由是：複合主鍵常常導致不良的外鍵，即當連接表成為另一個從表的主表，而依據上面的第二種方法成為這個表主鍵的一部分，然，這個表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠後的從表，其主鍵將會包含越多的列了。
3. 永遠也不要更新主鍵。實際上，因為主鍵除了惟一地標識一行之外，再沒有其他的用途了，所以也就沒有理由去對它更新。如果主鍵需要更新，表示主鍵應對使用者無意義的原則被違反了。
註：這項原則對於那些經常需要在資料轉換或多資料庫合併時進行資料整理的資料並不適用。
4. 主鍵不應包含動態變化的數據，如時間戳記、建立時間列、修改時間列等。
5. 主鍵應有計算機自動產生。如果由人來對主鍵的創建進行幹預，就會使它帶有除了惟一標識一行以外的意義。一旦越過這個界限，就可能產生認為修改主鍵的動機，這樣，這種系統用來連結記錄行、管理記錄行的關鍵手段就會落入不了解資料庫設計的人的手中。
外鍵是資料庫層級的完整性約束，就是資料庫基礎理論書中所說的「參照完整性」的資料庫實作方式。
外鍵屬性當然是可以去掉的，如果你不想再用這種約束，對程式設計當然不會有什麼影響，但相應的錄入資料的時候就不對錄入的資料進行「參照完整性」檢查了。
例如有兩個表
A(a,b) :a為主鍵，b為外鍵（來自於Bb)
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、外鍵總是關聯唯一的鍵欄位。
本文出自CSDN博客，轉載請標示出處： http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx