小議數據庫主鍵選取策略

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

　　常見的數據庫主鍵選取方式有
　　●自動增長字段
　　●手動增長字段
　　●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結構為例)

　　客戶端發送開始事務命令
　　客戶端提交主表更新
　　服務器返回@@IDENTITY
　　客戶端根據返回的主鍵更新從表緩沖
　　客戶端將從表提交服務器更新
　　客戶端提交事務

　　在這裡多了一次往返就會增加了事務處理的時間降低並發性能

　　如果不用自動增長型字段將是以下情景
　　客戶端發送開始事務命令
　　客戶端提交主表更新
　　客戶端提交從表更新
　　客戶端提交事務

　　因此我不贊成使用自動增長型字段作為主鍵與外鍵鏈接的紐帶

　　除此之外當我們需要在多個數據庫間進行數據的復制時(SQL Server的數據分發訂閱機制允許我們進行庫間的數據復制操作)自動增長型字段可能造成數據合並時的主鍵沖突設想一個數據庫中的Order表向另一個庫中的Order表復制數據庫時OrderID到底該不該自動增長呢?

　　ADONET允許我們在DataSet中將某一個字段設置為自動增長型字段但千萬記住這個自動增長字段僅僅是個占位符而已當數據庫進行更新時數據庫生成的值會自動取代ADONET分配的值所以為了防止用戶產生誤解建議大家將ADONET中的自動增長初始值以及增量都設置成此外在ADONET中我們可以為兩張表建立DataRelation這樣存在級聯關系的兩張表更新時一張表更新後另外一張表對應鍵的值也會自動發生變化這會大大減少了我們對存在級聯關系的兩表間更新時自動增長型字段帶來的麻煩

　　二手動增長型字段

　　既然自動增長型字段會帶來如此的麻煩我們不妨考慮使用手動增長型的字段也就是說主鍵的值需要自己維護通常情況下需要建立一張單獨的表存儲當前主鍵鍵值還用上面的例子來說這次我們新建一張表叫IntKey包含兩個字段KeyName以及KeyValue就像一個HashTable給一個KeyName就可以知道目前的KeyValue是什麼然後手工實現鍵值數據遞增在SQL Server中可以編寫這樣一個存儲過程讓取鍵值的過程自動進行代碼如下
　　CREATE PROCEDURE [GetKey]
　　@KeyName char()
　　@KeyValue int OUTPUT
　　AS
　　UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + WHERE KeyName = @KeyName
　　GO

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

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

　　三使用UniqueIdentifier

　　SQL Server為我們提供了UniqueIdentifier數據類型並提供了一個生成函數NEWID( )使用NEWID( )可以生成一個唯一的UniqueIdentifierUniqueIdentifier在數據庫中占用個字節出現重復的概率非常小以至於可以認為是我們經常從注冊表中看到類似
　　{FEBFEAABEAEDEECEC}

　　的東西實際上就是一個UniqueIdentifierWindows用它來做COM組件以及接口的標識防止出現重復在NET裡管UniqueIdentifier稱之為GUID(Global Unique Identifier)在C#中可以使用如下命令生成一個GUID
　　Guid u = SystemGuidNewGuid();

　　對於上面提到的Order與OrderDetail的程序如果選用UniqueIdentifier作為主鍵的話我們完全可以避免上面提到的增加網絡RoundTrip的問題通過程序直接生成GUID填充主鍵不用考慮是否會出現重復

　　UniqueIdentifier字段也存在嚴重的缺陷首先它的長度是字節是整數的倍長會占用大量存儲空間更為嚴重的是UniqueIdentifier的生成毫無規律可言要想在上面建立索引(絕大多數數據庫在主鍵上都有索引)是一個非常耗時的操作有人做過實驗插入同樣的數據量使用UniqueIdentifier型數據做主鍵要比使用Integer型數據慢所以出於效率考慮盡可能避免使用UniqueIdentifier型數據庫作為主鍵鍵值

　　四使用COMB(Combine)類型

　　既然上面三種主鍵類型選取策略都存在各自的缺點那麼到底有沒有好的辦法加以解決呢?答案是肯定的通過使用COMB類型(數據庫中沒有COMB類型它是Jimmy Nilsson在他的The Cost of GUIDs as Primary Keys一文中設計出來的)可以在三者之間找到一個很好的平衡點

　　COMB數據類型的基本設計思路是這樣的既然UniqueIdentifier數據因毫無規律可言造成索引效率低下影響了系統的性能那麼我們能不能通過組合的方式保留UniqueIdentifier的前個字節用後個字節表示GUID生成的時間(DateTime)這樣我們將時間信息與UniqueIdentifier組合起來在保留UniqueIdentifier的唯一性的同時增加了有序性以此來提高索引效率也許有人會擔心UniqueIdentifier減少到字節會造成數據出現重復其實不用擔心後字節的時間精度可以達到/秒兩個COMB類型數據完全相同的可能性是在這/秒內生成的兩個GUID前個字節完全相同這幾乎是不可能的!在SQL Server中用SQL命令將這一思路實現出來便是
　　DECLARE @aGuid UNIQUEIDENTIFIER
　　SET @aGuid = CAST(CAST(NEWID() AS BINARY())
　　+ CAST(GETDATE() AS BINARY()) AS UNIQUEIDENTIFIER)

　　經過測試使用COMB做主鍵比使用INT做主鍵在檢索插入更新刪除等操作上仍然顯慢但比Unidentifier類型要快上一些關於測試數據可以參考我年月日的隨筆

　　除了使用存儲過程實現COMB數據外我們也可以使用C#生成COMB數據這樣所有主鍵生成工作可以在客戶端完成C#代碼如下
　　/**////

　　/// 返回 GUID 用於數據庫操作特定的時間代碼可以提高檢索效率
　　///

　　/// COMB (GUID 與時間混合型) 類型 GUID 數據
　　public static Guid NewComb()
　　{
　　　　byte[] guidArray = SystemGuidNewGuid()ToByteArray();
　　　　DateTime baseDate = new DateTime();
　　　　DateTime now = DateTimeNow;
　　　　// Get the days and milliseconds which will be used to build the byte string
　　　　TimeSpan days = new TimeSpan(nowTicks baseDateTicks);
　　　　TimeSpan msecs = new TimeSpan(nowTicks (new DateTime(nowYear nowMonth nowDay)Ticks));
　　　　// Convert to a byte array
　　　　// Note that SQL Server is accurate to /th of a millisecond so we divide by
　　　　byte[] daysArray = BitConverterGetBytes(daysDays);
　　　　byte[] msecsArray = BitConverterGetBytes((long)(msecsTotalMilliseconds/));
　　　　// Reverse the bytes to match SQL Servers ordering
　　　　ArrayReverse(daysArray);
　　　　ArrayReverse(msecsArray);
　　　　// Copy the bytes into the guid
　　　　ArrayCopy(daysArray daysArrayLength guidArray guidArrayLength );
　　　　ArrayCopy(msecsArray msecsArrayLength guidArray guidArrayLength );
　　　　return new SystemGuid(guidArray);
　　}
　　/**////

　　/// 從 SQL SERVER 返回的 GUID 中生成時間信息
　　///

　　/// 包含時間信息的 COMB
　　/// 時間
　　public static DateTime GetDateFromComb(SystemGuid guid)
　　{
　　　　DateTime baseDate = new DateTime();
　　　　byte[] daysArray = new byte[];
　　　　byte[] msecsArray = new byte[];
　　　　byte[] guidArray = guidToByteArray();
　　　　// Copy the date parts of the guid to the respective byte arrays
　　　　ArrayCopy(guidArray guidArrayLength daysArray );
　　　　ArrayCopy(guidArray guidArrayLength msecsArray );
　　　　// Reverse the arrays to put them into the appropriate order
　　　　ArrayReverse(daysArray);
　　　　ArrayReverse(msecsArray);
　　　　// Convert the bytes to ints
　　　　int days = BitConverterToInt(daysArray );
　　　　int msecs = BitConverterToInt(msecsArray );
　　　　DateTime date = baseDateAddDays(days);
　　　　date = dateAddMilliseconds(msecs * );
　　　　return date;
　　}

　　結語

　　數據庫主鍵在數據庫中占有重要地位主鍵的選取策略決定了系統是否高效易用本文比較了四種主鍵選取策略的優缺點並提供了相應的代碼解決方案希望對大家有所幫助

From:http://tw.wingwit.com/Article/program/SQL/201311/16432.html