我們在建立資料庫的時候，需要為每張表指定一個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組，一個表只能有一個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行資料更新、刪除的時候不會出現張冠李戴的錯誤。當然，其它欄位可以輔助我們在執行這些操作時消除共享衝突，不過就不在這裡討論了。主鍵除了上述作用外，常常與外來鍵構成參照完整性約束，防止出現數據不一致。所以資料庫在設計時，主鍵起到了很重要的作用。

常見的資料庫主鍵選取方式有：

• 自動增長欄位

• 手動增長欄位

• UniqueIdentifier

• “COMB（Combine）”型別

1自動增長型欄位

很多資料庫設計者喜歡使用自動增長型欄位，因為它使用簡單。自動增長型欄位允許我們在向資料庫新增資料時，不考慮主鍵的取值，記錄插入後，資料庫系統會自動為其分配一個值，確保絕對不會出現重複。如果使用

儘管自動增長型欄位會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在資料緩衝模式下，很難預先填寫主鍵與外來鍵的值。假設有兩張表：

Order(OrderID, OrderDate)
OrderDetial(OrderID, LineNum, ProductID, Price)

Order表中的OrderID是自動增長型的欄位。現在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動增長型的欄位，那麼我們在記錄正式插入到資料庫之前無法事先得知它的取值，只有在更新後才能知道資料庫為它分配的是什麼值。這會造成以下矛盾發生：

首先，為了能在OrderDetail的OrderID欄位中添入正確的值，必須先更新Order表以獲取到系統為其分配的OrderID值，然後再用這個OrderID填充OrderDetail表。最後更新OderDetail表。但是，為了確保資料的一致性，Order與OrderDetail在更新時必須在事務保護下同時進行，即確保兩表同時更行成功。顯然它們是相互矛盾的。

除此之外，當我們需要在多個數據庫間進行資料的複製時（SQL Server的資料分發、訂閱機制允許我們進行庫間的資料複製操作），自動增長型欄位可能造成資料合併時的主鍵衝突。設想一個數據庫中的Order表向另一個庫中的Order表複製資料庫時，

ADO.NET允許我們在DataSet中將某一個欄位設定為自動增長型欄位，但千萬記住，這個自動增長欄位僅僅是個佔位符而已，當資料庫進行更新時，資料庫生成的值會自動取代ADO.NET分配的值。所以為了防止使用者產生誤解，建議大家將ADO.NET中的自動增長初始值以及增量都設定成-1。此外，在ADO.NET中，我們可以為兩張表建立DataRelation，這樣存在級聯關係的兩張表更新時，一張表更新後另外一張表對應鍵的值也會自動發生變化，這會大大減少了我們對存在級聯關係的兩表間更新時自動增長型欄位帶來的麻煩。

2手動增長型欄位

既然自動增長型欄位會帶來如此的麻煩，我們不妨考慮使用手動增長型的欄位，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表儲存當前主鍵鍵值。還用上面的例子來說，這次我們新建一張表叫IntKey，包含兩個欄位，KeyName以及KeyValue。就像一個HashTable，給一個KeyName，就可以知道目前的KeyValue是什麼，然後手工實現鍵值資料遞增。在SQL Server中可以編寫這樣一個儲存過程，讓取鍵值的過程自動進行。程式碼如下：

CREATEPROCEDURE[GetKey]

@KeyName char(10),
@KeyValue int OUTPUT

ASUPDATE IntKey SET @KeyValue = KeyValue = KeyValue +1WHERE KeyName = @KeyName
GO

這樣，通過呼叫儲存過程，我們可以獲得最新鍵值，確保不會出現重複。若將OrderID欄位設定為手動增長型欄位，我們的程式可以由以下幾步來實現：首先呼叫儲存過程，獲得一個OrderID，然後使用這個OrderID填充Order表與OrderDetail表，最後在事務保護下對兩表進行更新。

使用手動增長型欄位作為主鍵在進行資料庫間資料複製時，可以確保資料合併過程中不會出現鍵值衝突，只要我們為不同的資料庫分配不同的主鍵取值段就行了。但是，使用手動增長型欄位會增加網路的RoundTrip，我們必須通過增加一次資料庫訪問來獲取當前主鍵鍵值，這會增加網路和資料庫的負載，當處於一個低速或斷開的網路環境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮併發衝突等種種因素，這更會增加系統的複雜程度。

3使用UniqueIdentifier

SQL Server為我們提供了UniqueIdentifier資料型別，並提供了一個生成函式NEWID( )，使用NEWID( )可以生成一個唯一的UniqueIdentifier。UniqueIdentifier在資料庫中佔用16個位元組，出現重複的概率非常小，以至於可以認為是0。我們經常從登錄檔中看到類似

{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型資料庫作為主鍵鍵值。

4使用“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型別要快上一些。關於測試資料可以參考我2004年7月21日的隨筆。

除了使用儲存過程實現COMB資料外，我們也可以使用C#生成COMB資料，這樣所有主鍵生成工作可以在客戶端完成。C#程式碼如下：

//================================================================
///<summary>///返回 GUID 用於資料庫操作，特定的時間程式碼可以提高檢索效率///</summary>///<returns>COMB (GUID 與時間混合型) 型別 GUID 資料</returns>publicstatic 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);

     returnnew System.Guid(guidArray);
}

//================================================================
///<summary>///從 SQL SERVER 返回的 GUID 中生成時間資訊///</summary>///<param name="guid">包含時間資訊的 COMB </param>///<returns>時間</returns>publicstatic DateTime GetDateFromComb(System.Guid guid)
{
     DateTime baseDate = new DateTime(1900,1,1);
     byte[] daysArray = newbyte[4];
     byte[] msecsArray = newbyte[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;

}