SQL Server的主鍵和自動編號
所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組,一個表只能有一個主鍵,但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄,所以可以確保執行數據更新、刪除的時候不會出現張冠李戴的錯誤。
當然,其它字段可以輔助我們在執行這些操作時消除共享沖突,不過就不在這里討論了。主鍵除了上述作用外,常常與外鍵構成參照完整性約束,防止出現數據不一致。所以數據庫在設計時,主鍵起到了很重要的作用。
常見的數據庫主鍵選取方式有:
·自動增長字段
·手動增長字段
·UniqueIdentifier
·“COMB(Combine)”類型
一、自動增長型字段
很多數據庫設計者喜歡使用自動增長型字段,因為它使用簡單。自動增長型字段允許我們在向數據庫添加數據時,不考慮主鍵的取值,記錄插入后,數據庫系統會自 動為其分配一個值,確保絕對不會出現重復。如果使用SQL Server數據庫的話,我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統分配的主鍵鍵值。
盡管自動增長型字段會省掉我們很多繁瑣的工作,但使用它也存在潛在的問題,那就是在數據緩沖模式下,很難預先填寫主鍵與外鍵的值。假設有兩張表:
Order(OrderID, OrderDate)OrderDetial(OrderID, LineNum, ProductID, Price)
Order 表中的OrderID是自動增長型的字段。現在需要我們錄入一張訂單,包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記 錄。因為Order表中的OrderID是自動增長型的字段,那么我們在記錄正式插入到數據庫之前無法事先得知它的取值,只有在更新后才能知道數據庫為它 分配的是什么值。這會造成以下矛盾發生:
首先,為了能在 OrderDetail的OrderID字段中添入正確的值,必須先更新Order表以獲取到系統為其分配的OrderID值,然后再用這個 OrderID填充OrderDetail表。最后更新OderDetail表。但是,為了確保數據的一致性,Order與OrderDetail在更新 時必須在事務保護下同時進行,即確保兩表同時更行成功。
聽棠.NET指出:主檔放在事務中提交時,通過@@IDENTITY 就可以取到生成值的,因此可以傳給明細當外鍵用,而且在事務發生錯誤回滾時,主檔記錄也會被回滾取消的。
呂震宇補充:使用自動增長字段會增加網絡的roundTrip。盡管可以使用@@IDENTITY取得主鍵的值,但在更新過程中,不得不增加一次數據往返(以C/S結構為例):
1、客戶端發送開始事務命令
2、客戶端提交主表更新
3、服務器返回@@IDENTITY
4、客戶端根據返回的主鍵更新從表緩沖
5、客戶端將從表提交服務器更新
6、客戶端提交事務
在這里多了一次往返就會增加了事務處理的時間。降低并發性能。
如果不用自動增長型字段,將是以下情景:
1、客戶端發送開始事務命令
2、客戶端提交主表更新
3、客戶端提交從表更新
4、客戶端提交事務
因此我不贊成使用自動增長型字段作為主鍵與外鍵鏈接的紐帶。
除此之外,當我們需要在多個數據庫間進行數據的復制時(SQL Server的數據分發、訂閱機制允許我們進行庫間的數據復制操作),自動增長型字段可能造成數據合并時的主鍵沖突。設想一個數據庫中的Order表向另 一個庫中的Order表復制數據庫時,OrderID到底該不該自動增長呢?
ADO.NET允許我們在 DataSet中將某一個字段設置為自動增長型字段,但千萬記住,這個自動增長字段僅僅是個占位符而已,當數據庫進行更新時,數據庫生成的值會自動取代 ADO.NET分配的值。所以為了防止用戶產生誤解,建議大家將ADO.NET中的自動增長初始值以及增量都設置成-1。此外,在ADO.NET中,我們 可以為兩張表建立DataRelation,這樣存在級聯關系的兩張表更新時,一張表更新后另外一張表對應鍵的值也會自動發生變化,這會大大減少了我們對 存在級聯關系的兩表間更新時自動增長型字段帶來的麻煩。
二、手動增長型字段
既然自動增長型字段會帶來如此的麻煩,我們不妨考慮使用手動增長型的字段,也就是說主鍵的值需要自己維護,通常情況下需要建立一張單獨的表存儲當前主鍵鍵 值。還用上面的例子來說,這次我們新建一張表叫IntKey,包含兩個字段,KeyName以及KeyValue。就像一個HashTable,給一個 KeyName,就可以知道目前的KeyValue是什么,然后手工實現鍵值數據遞增。在SQL Server中可以編寫這樣一個存儲過程,讓取鍵值的過程自動進行。代碼如下:
CREATE PROCEDURE [GetKey]@KeyName char(10), @KeyValue int OUTPUTAS UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName GO
這樣,通過調用存儲過程,我們可以獲得最新鍵值,確保不會出現重復。若將OrderID字段設置為手動增長型字段,我們的程序可以由以下幾步來實現:首先 調用存儲過程,獲得一個OrderID,然后使用這個OrderID填充Order表與OrderDetail表,最后在事務保護下對兩表進行更新。
使用手動增長型字段作為主鍵在進行數據庫間數據復制時,可以確保數據合并過程中不會出現鍵值沖突,只要我們為不同的數據庫分配不同的主鍵取值段就行了。但 是,使用手動增長型字段會增加網絡的RoundTrip,我們必須通過增加一次數據庫訪問來獲取當前主鍵鍵值,這會增加網絡和數據庫的負載,當處于一個低 速或斷開的網絡環境中時,這種做法會有很大的弊端。同時,手工維護主鍵還要考慮并發沖突等種種因素,這更會增加系統的復雜程度。
三、使用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型 數據庫作為主鍵鍵值。
四、使用“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#代碼如下:
//================================================================/**////
/// 返回 GUID 用于數據庫操作,特定的時間代碼可以提高檢索效率
///
/// COMB (GUID 與時間混合型) 類型 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, days
Array.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 中生成時間信息
///
///
包含時間信息的 COMB
/// 時間
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;
}
小結:
數據庫主鍵在數據庫中占有重要地位。主鍵的選取策略決定了系統是否高效、易用。本文比較了四種主鍵選取策略的優缺點,并提供了相應的代碼解決方案,希望對大家有所幫助。
關鍵字:SQL Serve、數據庫、主鍵、自動編號
新文章:
- CentOS7下圖形配置網絡的方法
- CentOS 7如何添加刪除用戶
- 如何解決centos7雙系統后丟失windows啟動項
- CentOS單網卡如何批量添加不同IP段
- CentOS下iconv命令的介紹
- Centos7 SSH密鑰登陸及密碼密鑰雙重驗證詳解
- CentOS 7.1添加刪除用戶的方法
- CentOS查找/掃描局域網打印機IP講解
- CentOS7使用hostapd實現無AP模式的詳解
- su命令不能切換root的解決方法
- 解決VMware下CentOS7網絡重啟出錯
- 解決Centos7雙系統后丟失windows啟動項
- CentOS下如何避免文件覆蓋
- CentOS7和CentOS6系統有什么不同呢
- Centos 6.6默認iptable規則詳解