關係型數據庫主鍵總結

在基於關係型數據庫設計時候，一般要爲每張表指定一個主鍵，所謂主鍵就是可以惟一標識表中某一行記錄的屬性或屬性組，一個表只能有一個主鍵，但能夠 有多個候選索引。由於主鍵能夠惟一標識某一行記錄，因此能夠確保執行數據更新、刪除、修改時不出現錯誤。固然，其它字段能夠輔助咱們在執行這些操做時消除 共享衝突，不是本文討論的重點，再也不贅述。主鍵除了上述做用外，經常與外鍵構成參照完整性約束，防止出現數據不一致。因此數據庫在設計時，主鍵起到了很重 要的做用。常見的數據庫主鍵選取方式有： 自動增加式、手動增加式 、UniqueIdentifier、聯合式（複合式）、時間序列+隨機數式、「COMB（Combine）」類型。
1、自動增加式
不少數據庫設計者喜歡使用自動增加型字段，由於它使用簡單。自動增加式容許咱們在向數據庫添加數據時，不考慮主鍵的取值，記錄插入後，數據庫系統會 自動爲其分配一個值，確保絕對不會出現重複。若是使用SQL Server數據庫的話，咱們還能夠在記錄插入後使用@@IDENTITY全局變量獲取系統分配的主鍵值。 
儘管自動增加式字段會省掉咱們不少繁瑣的工做，但使用它也存在潛在的問題，那就是在數據緩衝模式下，很難預先填寫主鍵與外鍵的值。假設有主輔兩張表：
Order(OrderID, OrderDate)  訂單表
OrderDetial(OrderID, LineNum, ProductID, Price)  訂單明細表
Order 表中的OrderID是自動增加型的字段。假設如今須要咱們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條 記錄。由於Order表中的OrderID是自動增加型的字段，那麼咱們在記錄正式插入到數據庫以前沒法事先得知它的取值，只有在更新後才能知道數據庫爲 它分配的是什麼值。這會形成如下矛盾發生： 
首先，爲了能在OrderDetail的OrderID字段中添入正確的值，必須先更新 Order表以獲取到系統爲其分配的OrderID值，而後再用這個OrderID填充OrderDetail表的OrderID列。最後更新 OderDetail表。可是，爲了確保數據的一致性，Order與OrderDetail在更新時必須在事務模式下進行的，即要麼兩張表同時同時更新成 功、要麼所有失敗，顯然它們是相互矛盾的。 
 其次，當咱們須要在多個數據庫間進行數據的複製時（SQL Server的數據分發、訂閱機制容許咱們進行庫間的數據複製操做），自動增加式字段可能形成數據合併時的主鍵衝突及表關聯關係的丟失。設想一個數據庫中 的Order表向另外一個庫中的Order表複製數據庫時，OrderID到底該不應自動增加呢？若是自動增加，其子表OrderDetial的關聯關係會 丟失，若是不增加就會和現有數據主鍵重複，是否是很矛盾呢？ 
再次，自增量的值都是須要在系統中維護一個全局的數據值，每次插入數據時即對這次值進行增量取值。當在產生惟一標識的併發環境中，每次的增量取值都必須爲此全局值加鎖解鎖以保證增量的惟一性。形成併發瓶頸，下降查詢性能。
    還有當數據表足夠大或頻繁的更改和插入操做致使主鍵類型值超出範圍，這種狀況通常不多碰到，但也是咱們進行數據表設計時必須考慮的一個問題

在實際開發中中容易出現主鍵衝突 主鍵衝突就是主鍵出現重複值
好比 t_user t_admin 都有主鍵 都是id 自增方式
Insert into t_user (id)
Select id from t_admin
兩表中都有主鍵爲 7的時候 插入數據不成功 由於主鍵衝突
解決辦法
UPDATE t_admin SET id=-id
WHERE id IS NOT NULL AND id>0

Commit;

2、手動增加型字段
既然自動增加型字段會帶來如此的麻煩，咱們不妨考慮使用手動增加型的字段，也就是說主鍵的值須要本身維護，一般狀況下須要創建一張單獨的表存儲當前 主鍵鍵值。爲了敘述上的方便仍然利用上面的例子進行闡述，新建一張表叫IntKey，包含兩個字段，KeyName以及KeyValue。就像一個 HashTable，給一個KeyName，就能夠知道目前的KeyValue是什麼，而後手工實現鍵值數據遞增。在SQL Server中能夠編寫這樣一個存儲過程，讓取鍵值的過程自動進行。代碼以下：
CREATE PROCEDURE [GetKey] 
@KeyName char(10), 
@KeyValue int OUTPUT 
AS 
UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName 
GO
這樣，經過調用存儲過程，咱們能夠得到最新鍵值，確保不會出現重複。若將OrderID字段設置爲手動增加式字段，咱們的程序能夠由如下幾步來實 現：首先調用存儲過程，得到一個OrderID，而後使用這個OrderID填充Order表與OrderDetail表，最後在事務機制下對兩表進行更 新。 
使用手動增加式字段做爲主鍵在進行數據庫間數據複製時，能夠確保數據合併過程當中不會出現鍵值衝突，只要爲不一樣的數據表分配不一樣的主鍵取值段 就好了。可是，使用手動增加型字段會增長網絡的負擔，必須經過增長一次數據庫訪問來獲取當前主鍵鍵值，這會增長網絡和數據庫的負載，當處於一個低速或斷開 的網絡環境中時，這種作法會有很大的弊端。同時，手工維護主鍵還要考慮併發衝突等種種因素，這更會增長系統的複雜程度。
3、使用UniqueIdentifier
SQL Server爲咱們提供了UniqueIdentifier數據類型，並提供了一個生成函數NEWID( )，使用NEWID( )能夠生成一個惟一的UniqueIdentifier。UniqueIdentifier在數據庫中佔用16個字節，出現重複的機率幾乎爲0，號稱全球 惟一標識。咱們常常從註冊表或WINDOWS程序出現錯誤須要調試時看到相似 768427bf-9b37-4776-97ca-000365e160d5或{45F0EB02-0727-4F2E-AAB5- E8AEDEE0CEC5} 的東西實際上就是一個UniqueIdentifier，Windows用它來作COM組件以及接口的標識，防止出現重複。在.NET中 UniqueIdentifier稱之爲GUID（Global Unique Identifier）。在C#中可使用以下命令生成一個GUID： 
Guid u = System.Guid.NewGuid(); 
對 於上面提到的Order與OrderDetail的程序，若是選用UniqueIdentifier做爲主鍵的話，咱們徹底能夠避免上面提到的增長網絡 RoundTrip的問題。經過程序直接生成GUID填充主鍵，不用考慮是否會出現重複。 可是UniqueIdentifier 字段也存在嚴重的缺陷：首先，它的長度是16字節，是整數的4倍長，會佔用大量存儲空間。更爲嚴重的是，UniqueIdentifier的生成毫無規律 可言，也就是說是無序的，要想在上面創建索引（絕大多數數據庫在主鍵上都有索引）是一個很是耗時的操做。有人作過實驗，當數據表記錄比較大的時，在不一樣的 數據量級別上插入一樣的數據量，使用 UniqueIdentifier型數據作主鍵要比使用Integer型數據慢，且尚未考慮到表關聯的狀況，出於效率考慮，儘量避免使用 UniqueIdentifier型數據庫做爲主鍵值，但隨着現代計算機計算速度愈來愈快，在中小型項目中使用UniqueIdentifier式主鍵也 是一個選項。
4、使用業務字段聯合主鍵
    
基於DEPHI和 POWERBUILDER等數據庫工具開發C/S系統的數據庫設計人員，習慣上用有業務意義的字段組合成複合主鍵作數據表主鍵。使用業務主鍵固然有其與生 俱來的好處，通常狀況下數據庫系統會在默認條件下創建聚簇索引，並且這個聚簇索引基於主鍵升序排列，當數據量比較小時，咱們感受不到這種差異，當數據量比 較大時，這種基於主鍵定義的聚簇索引的優點就顯現出來，這就使得數據表在每次存取數據時按照索引準確確認數據插入或更新的磁盤物理位置，減小磁頭尋址時 間，從而提升數據庫性能，並且可以從業務意義上保證數據的完整性，增長程序的可靠性。可是基於業務字段的聯合索引，當業務字段選用比較多時會佔用比較多的 磁盤空間，並且索引頁會佔用更多的內存頁面，從而致使查詢命中率下降；另外使用業務主鍵，當涉及到主鍵數據的修改時，要在編程過程當中記錄新值和原值的關係 表，在更新時又要進行新值和原值的比對，增長編寫程序的複雜度。
5、時間序列+隨機數主鍵
採用精確到毫秒甚至鈉秒級的時間和一個隨機產生的兩位數作主鍵，如200911282311528+兩位隨機數，不失爲解決主鍵問題的一個有效辦 法。這樣產生的主鍵既避免了UniqueIdentifier型字段作主鍵時的無序，又能有效避免自動增加型主鍵帶來的諸如複製和數據導入的麻煩。但在使 用用戶衆多的網絡實時系統中，在時間和空間上仍然不能保證惟一性的問題。
6、使用「COMB（Combine）」類型
既然上面五種主鍵類型選取策略都存在各自的缺點，那麼到底有沒有好的辦法加以解決呢？答案是確定的。經過使用COMB類型（數據庫中沒有COMB類 型，它是Jimmy Nilsson在他的「The Cost of GUIDs as Primary Keys」一文中設計出來的），能夠在以上衆多的主鍵策略之間採用中庸之道，找到一個很好的平衡點。
COMB數據類型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無規律可言形成索引效率低下，影響了系統的性能，那麼咱們 能不能經過組合的方式，保留UniqueIdentifier的前10個字節，用後6個字節表示GUID生成的時間（DateTime），這樣咱們將時間 信息與 UniqueIdentifier組合起來，在保留UniqueIdentifier的惟一性的同時增長了有序性，以此來提升索引效率。也許有人會擔憂 UniqueIdentifier減小到10字節會形成數據出現重複，其實不用擔憂，後6字節的時間精度能夠達到1/300秒，兩個COMB類型數據徹底 相同的可能性是在這1/300秒內生成的兩個GUID前10個字節徹底相同，這幾乎是不可能的！在SQL Server中用SQL命令將這一思路實現出來即是：
DECLARE @aGuid UNIQUEIDENTIFIER 
SET @aGuid = CAST(CAST(NEWID() AS BINARY(10)) 

• CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)
  通過測試，使用COMB作主鍵比使用INT作主鍵，在檢索、插入、更新、刪除等操做上仍然顯慢，但比Unidentifier類型要快上一些。除了使用存儲過程實現COMB數據外，咱們也可使用C#生成COMB數據，這樣全部主鍵生成工做能夠在客戶端完成。
  C#代碼以下： 
  複製代碼代碼以下:

//================================================ 
/////<summary> 
/// 返回 GUID 用於數據庫操做，特定的時間代碼能夠提升檢索效率 
/// </summary> 
/// <returns>COMB (GUID 與時間混合型) 類型 GUID 數據</returns> 
public static Guid NewComb() 
{ 
byte[] guidArray = System.Guid.NewGuid().ToByteArray(); 
DateTime baseDate = new DateTime(1900,1,1); 
DateTime now = DateTime.Now; 
// Get the days and milliseconds which will be used to build the byte string 
TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks); 
TimeSpan msecs = new TimeSpan(now.Ticks - (new DateTime(now.Year, now.Month, now.Day).Ticks));
// Convert to a byte array 
// Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333 
byte[] daysArray = BitConverter.GetBytes(days.Days); 
byte[] msecsArray = BitConverter.GetBytes((long)(msecs.TotalMilliseconds/3.333333)); 
// Reverse the bytes to match SQL Servers ordering 
Array.Reverse(daysArray); 
Array.Reverse(msecsArray); 
// Copy the bytes into the guid 
Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2); 
Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4); 
return new System.Guid(guidArray); 
} 
//================================================ 
///// <summary> 
/// 從 SQL SERVER 返回的 GUID 中生成時間信息 
/// </summary> 
/// <param name="guid">包含時間信息的 COMB </param> 
/// <returns>時間</returns> 
public static DateTime GetDateFromComb(System.Guid guid) 
{ 
DateTime baseDate = new DateTime(1900,1,1); 
byte[] daysArray = new byte[4]; 
byte[] msecsArray = new byte[4]; 
byte[] guidArray = guid.ToByteArray(); 
// Copy the date parts of the guid to the respective byte arrays. 
Array.Copy(guidArray, guidArray.Length - 6, daysArray, 2, 2); 
Array.Copy(guidArray, guidArray.Length - 4, msecsArray, 0, 4); 
// Reverse the arrays to put them into the appropriate order 
Array.Reverse(daysArray); 
Array.Reverse(msecsArray); 
// Convert the bytes to ints 
int days = BitConverter.ToInt32(daysArray, 0); 
int msecs = BitConverter.ToInt32(msecsArray, 0); 
DateTime date = baseDate.AddDays(days); 
date = date.AddMilliseconds(msecs * 3.333333); 
return date; 
} 
綜上述六種主鍵選取策略，我認爲使用「COMB（Combine）」類型作主鍵是比較恰當的主鍵應用策略，但在實際使用過程當中要根據客觀實踐、因時因事選取適當的主鍵，切不可生搬硬套、弄巧成拙。