- 相關(guān)推薦
簡(jiǎn)述sqlserver數據庫主鍵選取策略
簡(jiǎn)述sqlserver數據庫主鍵選取策略
因為主鍵可以唯一標識某一行記錄，所以可以確保執行數據更新、刪除的時(shí)候不會(huì )出現張冠李戴的錯誤。當然，其它字段可以輔助我們在執行這些操作時(shí)消除共享沖突，不過(guò)就不在這里討論了。主鍵除了上述作用外，常常與外鍵構成參照完整性約束，防止出現數據不一致。所以數據庫在設計時(shí)，主鍵起到了很重要的作用。
常見(jiàn)的數據庫主鍵選取方式有：
自動(dòng)增長(cháng)字段
手動(dòng)增長(cháng)字段
UniqueIdentifier
“COMB（Combine）”類(lèi)型
一、自動(dòng)增長(cháng)型字段
很多數據庫設計者喜歡使用自動(dòng)增長(cháng)型字段，因為它使用簡(jiǎn)單。自動(dòng)增長(cháng)型字段允許我們在向數據庫添加數據時(shí)，不考慮主鍵的取值，記錄插入后，數據庫系統會(huì )自動(dòng)為其分配一個(gè)值，確保絕對不會(huì )出現重復。如果使用SQL Server數據庫的話(huà)，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統分配的主鍵鍵值。
盡管自動(dòng)增長(cháng)型字段會(huì )省掉我們很多繁瑣的工作，但使用它也存在潛在的問(wèn)題，那就是在數據緩沖模式下，很難預先填寫(xiě)主鍵與外鍵的值。假設有兩張表：
Order(OrderID, OrderDate)
OrderDetial(OrderID, LineNum, ProductID, Price)
Order表中的OrderID是自動(dòng)增長(cháng)型的字段�，F在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動(dòng)增長(cháng)型的字段，那么我們在記錄正式插入到數據庫之前無(wú)法事先得知它的取值，只有在更新后才能知道數據庫為它分配的是什么值。這會(huì )造成以下矛盾發(fā)生：
首先，為了能在OrderDetail的OrderID字段中添入正確的值，必須先更新Order表以獲取到系統為其分配的OrderID值，然后再用這個(gè)OrderID填充OrderDetail表。最后更新OderDetail表。但是，為了確保數據的一致性，Order與 OrderDetail在更新時(shí)必須在事務(wù)保護下同時(shí)進(jìn)行，即確保兩表同時(shí)更行成功。顯然它們是相互矛盾的。（此處表述有錯誤。呂震宇 2005-6-15）
【補充2005-6-15】---------------------------------------------
聽(tīng)棠.NET指出：主檔放在事務(wù)中提交時(shí)，通過(guò)@@IDENTITY 就可以取到生成值的，因此可以傳給明細當外鍵用，而且在事務(wù)發(fā)生錯誤回滾時(shí)，主檔記錄也會(huì )被回滾取消的。
呂震宇補充：使用自動(dòng)增長(cháng)字段會(huì )增加網(wǎng)絡(luò )的roundTrip。盡管可以使用@@IDENTITY取得主鍵的值，但在更新過(guò)程中，不得不增加一次數據往返（以C/S結構為例）：
1、客戶(hù)端發(fā)送開(kāi)始事務(wù)命令
2、客戶(hù)端提交主表更新
3、服務(wù)器返回@@IDENTITY
4、客戶(hù)端根據返回的主鍵更新從表緩沖
5、客戶(hù)端將從表提交服務(wù)器更新
6、客戶(hù)端提交事務(wù)
在這里多了一次往返就會(huì )增加了事務(wù)處理的時(shí)間。降低并發(fā)性能。
如果不用自動(dòng)增長(cháng)型字段，將是以下情景：
1、客戶(hù)端發(fā)送開(kāi)始事務(wù)命令
2、客戶(hù)端提交主表更新
3、客戶(hù)端提交從表更新
4、客戶(hù)端提交事務(wù)
因此我不贊成使用自動(dòng)增長(cháng)型字段作為主鍵與外鍵鏈接的紐帶。
------------------------------------------------
除此之外，當我們需要在多個(gè)數據庫間進(jìn)行數據的復制時(shí)（SQL Server的數據分發(fā)、訂閱機制允許我們進(jìn)行庫間的數據復制操作），自動(dòng)增長(cháng)型字段可能造成數據合并時(shí)的.主鍵沖突。設想一個(gè)數據庫中的Order表向另一個(gè)庫中的Order表復制數據庫時(shí)，OrderID到底該不該自動(dòng)增長(cháng)呢？
ADO.NET允許我們在DataSet中將某一個(gè)字段設置為自動(dòng)增長(cháng)型字段，但千萬(wàn)記住，這個(gè)自動(dòng)增長(cháng)字段僅僅是個(gè)占位符而已，當數據庫進(jìn)行更新時(shí)，數據庫生成的值會(huì )自動(dòng)取代ADO.NET分配的值。所以為了防止用戶(hù)產(chǎn)生誤解，建議大家將ADO.NET中的自動(dòng)增長(cháng)初始值以及增量都設置成-1。此外，在A(yíng)DO.NET中，我們可以為兩張表建立DataRelation，這樣存在級聯(lián)關(guān)系的兩張表更新時(shí)，一張表更新后另外一張表對應鍵的值也會(huì )自動(dòng)發(fā)生變化，這會(huì )大大減少了我們對存在級聯(lián)關(guān)系的兩表間更新時(shí)自動(dòng)增長(cháng)型字段帶來(lái)的麻煩。
二、手動(dòng)增長(cháng)型字段
既然自動(dòng)增長(cháng)型字段會(huì )帶來(lái)如此的麻煩，我們不妨考慮使用手動(dòng)增長(cháng)型的字段，也就是說(shuō)主鍵的值需要自己維護，通常情況下需要建立一張單獨的表存儲當前主鍵鍵值。還用上面的例子來(lái)說(shuō)，這次我們新建一張表叫IntKey，包含兩個(gè)字段，KeyName以及KeyValue。就像一個(gè)HashTable，給一個(gè)KeyName，就可以知道目前的KeyValue是什么，然后手工實(shí)現鍵值數據遞增。在SQL Server中可以編寫(xiě)這樣一個(gè)存儲過(guò)程，讓取鍵值的過(guò)程自動(dòng)進(jìn)行。代碼如下：
復制代碼 代碼如下:
CREATE PROCEDURE [GetKey]
@KeyName 10),
@KeyValue int OUTPUT
AS
UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName
GO
這樣，通過(guò)調用存儲過(guò)程，我們可以獲得最新鍵值，確保不會(huì )出現重復。若將OrderID字段設置為手動(dòng)增長(cháng)型字段，我們的程序可以由以下幾步來(lái)實(shí)現：首先調用存儲過(guò)程，獲得一個(gè)OrderID，然后使用這個(gè)OrderID填充Order表與OrderDetail表，最后在事務(wù)保護下對兩表進(jìn)行更新。
使用手動(dòng)增長(cháng)型字段作為主鍵在進(jìn)行數據庫間數據復制時(shí)，可以確保數據合并過(guò)程中不會(huì )出現鍵值沖突，只要我們?yōu)椴煌臄祿䦷旆峙洳煌闹麈I取值段就行了。但是，使用手動(dòng)增長(cháng)型字段會(huì )增加網(wǎng)絡(luò )的RoundTrip，我們必須通過(guò)增加一次數據庫訪(fǎng)問(wèn)來(lái)獲取當前主鍵鍵值，這會(huì )增加網(wǎng)絡(luò )和數據庫的負載，當處于一個(gè)低速或斷開(kāi)的網(wǎng)絡(luò )環(huán)境中時(shí)，這種做法會(huì )有很大的弊端。同時(shí)，手工維護主鍵還要考慮并發(fā)沖突等種種因素，這更會(huì )增加系統的復雜程度。
三、使用UniqueIdentifier
SQL Server為我們提供了UniqueIdentifier數據類(lèi)型，并提供了一個(gè)生成函數NEWID( )，使用NEWID( )可以生成一個(gè)唯一的UniqueIdentifier。UniqueIdentifier在數據庫中占用16個(gè)字節，出現重復的概率非常小，以至于可以認為是0。我們經(jīng)常從注冊表中看到類(lèi)似
{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}
的東西實(shí)際上就是一個(gè)UniqueIdentifier，Windows用它來(lái)做COM組件以及接口的標識，防止出現重復。在.NET里管 UniqueIdentifier稱(chēng)之為GUID（Global Unique Identifier）。在C#中可以使用如下命令生成一個(gè)GUID：
Guid u = System.Guid.NewGuid();
對于上面提到的Order與OrderDetail的程序，如果選用UniqueIdentifier作為主鍵的話(huà)，我們完全可以避免上面提到的增加網(wǎng)絡(luò )RoundTrip的問(wèn)題。通過(guò)程序直接生成GUID填充主鍵，不用考慮是否會(huì )出現重復。
UniqueIdentifier字段也存在嚴重的缺陷：首先，它的長(cháng)度是16字節，是整數的4倍長(cháng)，會(huì )占用大量存儲空間。更為嚴重的是，UniqueIdentifier的生成毫無(wú)規律可言，要想在上面建立索引（絕大多數數據庫在主鍵上都有索引）是一個(gè)非常耗時(shí)的操作。有人做過(guò)實(shí)驗，插入同樣的數據量，使用UniqueIdentifier型數據做主鍵要比使用Integer型數據慢，所以，出于效率考慮，盡可能避免使用 UniqueIdentifier型數據庫作為主鍵鍵值。
四、使用“COMB（Combine）”類(lèi)型
既然上面三種主鍵類(lèi)型選取策略都存在各自的缺點(diǎn)，那么到底有沒(méi)有好的辦法加以解決呢？答案是肯定的。通過(guò)使用COMB類(lèi)型（數據庫中沒(méi)有COMB類(lèi)型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來(lái)的），可以在三者之間找到一個(gè)很好的平衡點(diǎn)。
COMB數據類(lèi)型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無(wú)規律可言造成索引效率低下，影響了系統的性能，那么我們能不能通過(guò)組合的方式，保留UniqueIdentifier的前10個(gè)字節，用后6個(gè)字節表示GUID生成的時(shí)間（DateTime），這樣我們將時(shí)間信息與UniqueIdentifier組合起來(lái)，在保留UniqueIdentifier的唯一性的同時(shí)增加了有序性，以此來(lái)提高索引效率。也許有人會(huì )擔心UniqueIdentifier減少到10字節會(huì )造成數據出現重復，其實(shí)不用擔心，后6字節的時(shí)間精度可以達到1/300秒，兩個(gè)COMB類(lèi)型數據完全相同的可能性是在這1/300秒內生成的兩個(gè)GUID前10個(gè)字節完全相同，這幾乎是不可能的！在SQL Server中用SQL命令將這一思路實(shí)現出來(lái)便是：
復制代碼 代碼如下:
DECLARE @aGuid UNIQUEIDENTIFIER
SET @aGuid = CAST(CAST(NEWID() AS BINARY(10))
+ CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)
經(jīng)過(guò)測試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類(lèi)型要快上一些。關(guān)于測試數據可以參考我2004年7月21日的隨筆。
除了使用存儲過(guò)程實(shí)現COMB數據外，我們也可以使用C#生成COMB數據，這樣所有主鍵生成工作可以在客戶(hù)端完成。C#代碼如下：
復制代碼 代碼如下:
//================================================================
///
/// 返回 GUID 用于數據庫操作，特定的時(shí)間代碼可以提高檢索效率
///
///COMB (GUID 與時(shí)間混合型) 類(lèi)型 GUID 數據
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);
}
//================================================================
///
/// 從 SQL SERVER 返回的 GUID 中生成時(shí)間信息
///
///包含時(shí)間信息的 COMB
///時(shí)間
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;
}
結語(yǔ)
數據庫主鍵在數據庫中占有重要地位。主鍵的選取策略決定了系統是否高效、易用。本文比較了四種主鍵選取策略的優(yōu)缺點(diǎn)，并提供了相應的代碼解決方案，希望對大家有所幫助。