關于數據庫設計中主鍵問題的思考

更新時間：2013年08月27日 22:31:13 作者：

數據庫主鍵在數據庫中占有重要地位。主鍵的選取策略決定了系統(tǒng)是否可靠、易用、高效。本文探討了數據庫設計過程當中常見的主鍵選取策略，并剖析了其做主鍵的優(yōu)缺點，提出了相應的解決問題的方法

在基于關系型數據庫設計時候，通常要為每張表指定一個主鍵，所謂主鍵就是能夠唯一標識表中某一行記錄的屬性或屬性組，一個表只能有一個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執(zhí)行數據更新、刪除、修改時不出現錯誤。當然，其它字段可以輔助我們在執(zhí)行這些操作時消除共享沖突，不是本文討論的重點，不再贅述。主鍵除了上述作用外，常常與外鍵構成參照完整性約束，防止出現數據不一致。所以數據庫在設計時，主鍵起到了很重要的作用。常見的數據庫主鍵選取方式有：自動增長式、手動增長式、UniqueIdentifier、聯合式（復合式）、時間序列+隨機數式、“COMB（Combine）”類型。

一、自動增長式

很多數據庫設計者喜歡使用自動增長型字段，因為它使用簡單。自動增長式允許我們在向數據庫添加數據時，不考慮主鍵的取值，記錄插入后，數據庫系統(tǒng)會自動為其分配一個值，確保絕對不會出現重復。如果使用SQL Server數據庫的話，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統(tǒng)分配的主鍵值。
盡管自動增長式字段會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在數據緩沖模式下，很難預先填寫主鍵與外鍵的值。假設有主輔兩張表：

Order(OrderID, OrderDate) 訂單表
OrderDetial(OrderID, LineNum, ProductID, Price) 訂單明細表

Order 表中的OrderID是自動增長型的字段。假設現在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動增長型的字段，那么我們在記錄正式插入到數據庫之前無法事先得知它的取值，只有在更新后才能知道數據庫為它分配的是什么值。這會造成以下矛盾發(fā)生：
首先，為了能在OrderDetail的OrderID字段中添入正確的值，必須先更新 Order表以獲取到系統(tǒng)為其分配的OrderID值，然后再用這個OrderID填充OrderDetail表的OrderID列。最后更新OderDetail表。但是，為了確保數據的一致性，Order與OrderDetail在更新時必須在事務模式下進行的，即要么兩張表同時同時更新成功、要么全部失敗，顯然它們是相互矛盾的。
其次，當我們需要在多個數據庫間進行數據的復制時（SQL Server的數據分發(fā)、訂閱機制允許我們進行庫間的數據復制操作），自動增長式字段可能造成數據合并時的主鍵沖突及表關聯關系的丟失。設想一個數據庫中的Order表向另一個庫中的Order表復制數據庫時，OrderID到底該不該自動增長呢？如果自動增長，其子表OrderDetial的關聯關系會丟失，如果不增長就會和現有數據主鍵重復，是不是很矛盾呢？
再次，自增量的值都是需要在系統(tǒng)中維護一個全局的數據值，每次插入數據時即對此次值進行增量取值。當在產生唯一標識的并發(fā)環(huán)境中，每次的增量取值都必須為此全局值加鎖解鎖以保證增量的唯一性。造成并發(fā)瓶頸，降低查詢性能。
還有當數據表足夠大或頻繁的更改和插入操作導致主鍵類型值超出范圍，這種情況一般很少碰到，但也是我們進行數據表設計時必須考慮的一個問題

二、手動增長型字段

既然自動增長型字段會帶來如此的麻煩，我們不妨考慮使用手動增長型的字段，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表存儲當前主鍵鍵值。為了敘述上的方便仍然利用上面的例子進行闡述，新建一張表叫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表，最后在事務機制下對兩表進行更新。
使用手動增長式字段作為主鍵在進行數據庫間數據復制時，可以確保數據合并過程中不會出現鍵值沖突，只要為不同的數據表分配不同的主鍵取值段就行了。但是，使用手動增長型字段會增加網絡的負擔，必須通過增加一次數據庫訪問來獲取當前主鍵鍵值，這會增加網絡和數據庫的負載，當處于一個低速或斷開的網絡環(huán)境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮并發(fā)沖突等種種因素，這更會增加系統(tǒng)的復雜程度。

三、使用UniqueIdentifier

SQL Server為我們提供了UniqueIdentifier數據類型，并提供了一個生成函數NEWID( )，使用NEWID( )可以生成一個唯一的UniqueIdentifier。UniqueIdentifier在數據庫中占用16個字節(jié)，出現重復的概率幾乎為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字節(jié)，是整數的4倍長，會占用大量存儲空間。更為嚴重的是，UniqueIdentifier的生成毫無規(guī)律可言，也就是說是無序的，要想在上面建立索引（絕大多數數據庫在主鍵上都有索引）是一個非常耗時的操作。有人做過實驗，當數據表記錄比較大的時，在不同的數據量級別上插入同樣的數據量，使用 UniqueIdentifier型數據做主鍵要比使用Integer型數據慢，且還沒有考慮到表關聯的情況，出于效率考慮，盡可能避免使用UniqueIdentifier型數據庫作為主鍵值，但隨著現代計算機計算速度越來越快，在中小型項目中使用UniqueIdentifier式主鍵也是一個選項。

四、使用業(yè)務字段聯合主鍵

基于DEPHI和POWERBUILDER等數據庫工具開發(fā)C/S系統(tǒng)的數據庫設計人員，習慣上用有業(yè)務意義的字段組合成復合主鍵做數據表主鍵。使用業(yè)務主鍵當然有其與生俱來的好處，一般情況下數據庫系統(tǒng)會在默認條件下建立聚簇索引，而且這個聚簇索引基于主鍵升序排列，當數據量比較小時，我們感覺不到這種差別，當數據量比較大時，這種基于主鍵定義的聚簇索引的優(yōu)勢就顯現出來，這就使得數據表在每次存取數據時按照索引準確確認數據插入或更新的磁盤物理位置，減少磁頭尋址時間，從而提高數據庫性能，而且能夠從業(yè)務意義上保證數據的完整性，增加程序的可靠性。但是基于業(yè)務字段的聯合索引，當業(yè)務字段選用比較多時會占用比較多的磁盤空間，而且索引頁會占用更多的內存頁面，從而導致查詢命中率降低；另外使用業(yè)務主鍵，當涉及到主鍵數據的修改時，要在編程過程中記錄新值和原值的關系表，在更新時又要進行新值和原值的比對，增加編寫程序的復雜度。

五、時間序列+隨機數主鍵

采用精確到毫秒甚至鈉秒級的時間和一個隨機產生的兩位數做主鍵，如200911282311528+兩位隨機數，不失為解決主鍵問題的一個有效辦法。這樣產生的主鍵既避免了UniqueIdentifier型字段做主鍵時的無序，又能有效避免自動增長型主鍵帶來的諸如復制和數據導入的麻煩。但在使用用戶眾多的網絡實時系統(tǒng)中，在時間和空間上仍然不能保證唯一性的問題。

六、使用“COMB（Combine）”類型

既然上面五種主鍵類型選取策略都存在各自的缺點，那么到底有沒有好的辦法加以解決呢？答案是肯定的。通過使用COMB類型（數據庫中沒有COMB類型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來的），可以在以上眾多的主鍵策略之間采用中庸之道，找到一個很好的平衡點。

COMB數據類型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無規(guī)律可言造成索引效率低下，影響了系統(tǒng)的性能，那么我們能不能通過組合的方式，保留UniqueIdentifier的前10個字節(jié)，用后6個字節(jié)表示GUID生成的時間（DateTime），這樣我們將時間信息與 UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。也許有人會擔心 UniqueIdentifier減少到10字節(jié)會造成數據出現重復，其實不用擔心，后6字節(jié)的時間精度可以達到1/300秒，兩個COMB類型數據完全相同的可能性是在這1/300秒內生成的兩個GUID前10個字節(jié)完全相同，這幾乎是不可能的！在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）”類型做主鍵是比較恰當的主鍵應用策略，但在實際使用過程中要根據客觀實踐、因時因事選取適當的主鍵，切不可生搬硬套、弄巧成拙。

參考文獻：

1、《系統(tǒng)分析師教程》張友生主編
2、《中文版SQL Server 2000開發(fā)與管理應用實例》鄒建主編
3、《數據庫中使用自增量字段與Guid字段主鍵的性能對比》作者不詳
4、《小議數據庫主鍵選取策略》作者不詳