主鍵和外鍵是把多個表組織為一個有效的關系數據庫的粘合劑。主鍵和外鍵的設計對物理數據庫的性能和可用性都有著決定性的影響。 必須將數據庫模式從理論上的邏輯設計轉換為實際的物理設計。而主鍵和外鍵的結構是這個設計過程的癥結所在。一旦將所設計的數據庫

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

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

主鍵：

關系數據庫依賴于主鍵---它是數據庫物理模式的基石。主鍵在物理層面上只有兩個用途：

1. 惟一地標識一行。

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

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

1. 主鍵應當是對用戶沒有意義的。如果用戶看到了一個表示多對多關系的連接表中的數據，并抱怨它沒有什么用處，那就證明它的主鍵設計地很好。

2. 主鍵應該是單列的，以便提高連接和篩選操作的效率。

注：使用復合鍵的人通常有兩個理由為自己開脫，而這兩個理由都是錯誤的。其一是主鍵應當具有實際意義，然而，讓主鍵具有意義只不過是給人為地破壞數據庫提供了方便。其二是利用這種方法可以在描述多對多關系的連接表中使用兩個外部鍵來作為主鍵，我也反對這種做法，理由是：復合主鍵常常導致不良的外鍵，即當連接表成為另一個從表的主表，而依據上面的第二種方法成為這個表主鍵的一部分，然，這個表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠后的從表，其主鍵將會包含越多的列了。

3. 永遠也不要更新主鍵。實際上，因為主鍵除了惟一地標識一行之外，再沒有其他的用途了，所以也就沒有理由去對它更新。如果主鍵需要更新，則說明主鍵應對用戶無意義的原則被違反了。

注：這項原則對于那些經常需要在數據轉換或多數據庫合并時進行數據整理的數據并不適用。

4. 主鍵不應包含動態變化的數據，如時間戳、創建時間列、修改時間列等。

5. 主鍵應當有計算機自動生成。如果由人來對主鍵的創建進行干預，就會使它帶有除了惟一標識一行以外的意義。一旦越過這個界限，就可能產生認為修改主鍵的動機，這樣，這種系統用來鏈接記錄行、管理記錄行的關鍵手段就會落入不了解數據庫設計的人的手中。

數據庫外鍵的使用

外鍵的作用我認為主要有兩個：一個是讓數據庫自己通過外鍵來保證數據的完整性和一致性，一個就是能夠增加ER圖的可讀性。我覺得第二點的重要性甚至比第一點還高。

有些人認為外鍵的建立會給開發時操作數據庫帶來很大的麻煩，因為數據庫有時候會由于沒有通過外鍵的檢測而使得開發人員刪除,插入操作失敗，他們覺得這樣很麻煩，其實這正式外鍵在強制你保證數據的完整性和一致性，這是好事兒。

應該說如果系統比較小，外鍵的作用可能不會很明顯，如果你的系統后臺有幾百個表的話，沒有外鍵的數據庫設計是我無法想象的，有一個基礎數據的表:商品，其他表都保存商品ID ，查詢時需要連表來查詢商品的名稱，單據1的商品表中有商品ID字段，單據2的商品表中也有商品ID字段，如果不拉出外鍵的話，當單據1,2都使用商品ID為3的商品后，刪除此商品后，再查看單據1,2的時候就會查不到商品的名稱

當表很少的時候，有人認為可以在程序實現的時候來通過寫腳本來保證數據的完整性和一致性，也就是在刪除商品的操作的時候去檢測單據1,2中是否已經使用了商品ID為3的商品，但是當你寫完腳本之后系統有增加了一個單據3
他也保存商品ID找個字段，如果不拉出外鍵，你還是會出現查不到商品名稱的情況，你總不能每增加一個使用商品ID的字段的單據時就回去修改你檢測商品是否被使用的腳本吧

第二點就是增加ER圖的可讀性。這也同樣是在后臺數據庫表非常多的時候能夠體現出來的，外鍵能夠明確的兩個表之間的關系，例如一個單據的主表和單據的品的子表，如果兩個表沒有拉出外鍵表明關系,且兩個表的位置在ER圖中很遠，對于一個對這個系統不是非常了解的人來說，讓他去理出兩個表之間的關系是很麻煩的，如果你拉出外鍵就算兩個表離的很遠，他也能隨著外鍵找出他們之間的關系來，ER圖的可讀性對于一個剛剛接觸大型系統的新手來說是極為重要的。

當然，外鍵的個數也不是沒有個尺度，因為外鍵拉的過多會使ER圖極為混亂(到處都是線) ，所以應該掌握合適的尺度才行，必要的外鍵必須要拉出來。如果實在不想因為外鍵過多而造成ER圖的混亂，可以對基礎數據的刪除用假刪除的辦法，以避免在沒有外鍵約束和檢查的情況下造成數據的不一致性。

uniqueidentifier數據類型

uniqueidentifier數據類型可存儲16字節的二進制值，其作用與全局唯一標記符（GUID）一樣。GUID是唯一的二進制數：世界上的任何兩臺計算機都不會生成重復的GUID值。GUID主要用于在用于多個節點，多臺計算機的網絡中，分配必須具有唯一性的標識符。 在SQL中 ROWGUIDCOL表示新列是行的全局唯一標識列。對于每個表只能指派一個uniqueidentifier 列作為ROWGUIDCO列。ROWGUIDCOL屬性只能指派給uniqueidentifier列
一 什么是uniqueidentifier？
Uniqqueidentifier 是全局唯一的標識

p d [3~)F F C E0二 UniqueIdentifier 數據類型的列如何賦值？
1 使用 NewID（）函數 來實現
2 直接將字符串的常量轉化成這樣的格式 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
舉例：6F9619FF-8B86-D011-B42D-00C04FC964FF 為有效的UniqueIdentifier數據
3 直接賦于32位的十六位數據
舉例 0xffffffff00000000ffffffff00000000
三 UniqueIdentifier 數據類型 數據實際是怎么在數據庫中保存的？
UniqueIdentifier 數據類型存儲實際的數據是16個字節的二進制值，
UniQueIdentifier 可以轉化成實際的字符串型和二進制數據類型

四 NewID（）函數是如何生成唯一的UniqueIdentifier 值的呢？
NewID（）函數是從他們的網卡上的標識數字和CPU時鐘的唯一的數字生成新的UniqueIdentifier數據 ，這個數據和GUID是一樣的每臺計算機能生成全球唯一的值
這樣在多臺計算機和多網絡之間生成具有唯一性的標識符

五 使用 Uniqueidentifier數據類型的主要的優點
Uniqueidentifier 數據類型主要的優點是在使用newid函數生成值的時候是可以保證值的全球唯一性
可以唯一的標識單行的記錄 對于多庫（尤其是多機器，多網段的數據庫的復制）來將比IDEntity來的更有效
其次在使用Identity的情況下，我們對自動生成的值是不能修改的，而Uniqueidentifier數據類型是可以隨時修改的

六 使用Uniqueidentifier的數據類型的缺點
1 對于生成的Uniqueidentifier 類型的值來講 ，是無序
在正常顯示相關的數據信息的時候，返回的信息是無序的ITPUB個人空間 p e%A _0`2I l(G!v t0]
對于 Identity 為標識的數據顯示的時候，默認的情況下是根據添加記錄的順序來顯示的。這樣，對于uniqueidentifier為主鍵的信息集 ，還是需要一個默認標識排序的字段。

2 對于Uniqueidentifier 字段來將數據的實際的信息為16個字節，相對來將比Identity來講 大的多，相對來將 存儲空間和查詢的效率會降低很多的。

七 在系統數據庫的設計中我們如何對Uniqueidentifier,Identity ,和可標識的記錄屬性（有實際的含義的信息）作為主鍵 ，這三種方式 進行取舍

以屬性為主鍵的系統設計情況
在系統設計的過程中
單條信息中包含可以表示唯一性的屬性（一般不能太多3個以內）而且這樣的屬性是必填字段。在記錄生存周期內一般是不進行改動的，表一般多于50個這樣級別的系統
以屬性為主鍵 ，這樣的方式還是最佳的

舉例： 關于學生的管理信息系統 以學生的學號為主鍵

以Uniqueidentifier 列為主鍵的情況
在需要多個數據庫之間，多個網段之間需要進行數據庫的復制時，我們就需要在每一個唯一的標識來區別每一個單條記錄，在沒有合適的屬性來做主鍵的情況下可以用Uniqueidentifier列來生成主鍵

以 Identity為主鍵的情況
不需要數據庫的復制，和系統比較小的情況下（50表以內）可以用 Identity列來生成主鍵，適合于快速開發

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com