我們?cè)诮?shù)據(jù)庫的時(shí)候，需要為每張表指定一個(gè)主鍵，所謂主鍵就是能夠唯一標(biāo)識(shí)表中某一 行的屬性或?qū)傩越M，一個(gè)表只能有一個(gè)主鍵，但可以有多個(gè)候選索引。因?yàn)橹麈I可以唯一標(biāo)識(shí)某一行記錄，所以可以確保執(zhí)行數(shù)據(jù)更新、刪除的時(shí)候不會(huì)出現(xiàn)張冠李 戴的錯(cuò)誤。當(dāng)然，其它字段可以輔助我們?cè)趫?zhí)行這些操作時(shí)消除共享沖突，不過就不在這里討論了。主鍵除了上述作用外，常常與外鍵構(gòu)成參照完整性約束，防止出 現(xiàn)數(shù)據(jù)不一致。所以數(shù)據(jù)庫在設(shè)計(jì)時(shí)，主鍵起到了很重要的作用。

常見的數(shù)據(jù)庫主鍵選取方式有：

• 自動(dòng)增長字段
• 手動(dòng)增長字段
• UniqueIdentifier
• “COMB（Combine）”類型

一、自動(dòng)增長型字段

很多數(shù)據(jù)庫設(shè)計(jì)者喜歡使用自動(dòng)增長型字段，因?yàn)樗褂煤唵巍Ｗ詣?dòng)增長型字段允許我們?cè)谙驍?shù)據(jù)庫添加數(shù)據(jù)時(shí)，不考慮主鍵的取值，記錄插入后，數(shù)據(jù)庫系統(tǒng)會(huì)自動(dòng)為其分配一個(gè)值，確保絕對(duì)不會(huì)出現(xiàn)重復(fù)。如果使用SQL Server數(shù)據(jù)庫的話，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統(tǒng)分配的主鍵鍵值。

盡管自動(dòng)增長型字段會(huì)省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在數(shù)據(jù)緩沖模式下，很難預(yù)先填寫主鍵與外鍵的值。假設(shè)有兩張表：

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

Order表中的OrderID是自動(dòng)增長型的字段。現(xiàn)在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表 中插入若干條記錄。因?yàn)镺rder表中的OrderID是自動(dòng)增長型的字段，那么我們?cè)谟涗浾讲迦氲綌?shù)據(jù)庫之前無法事先得知它的取值，只有在更新后才能 知道數(shù)據(jù)庫為它分配的是什么值。這會(huì)造成以下矛盾發(fā)生：

首先，為了能在OrderDetail的OrderID字段中添入正確的值，必須先更新Order表以獲取到系統(tǒng)為其分配的OrderID值，然后 再用這個(gè)OrderID填充OrderDetail表。最后更新OderDetail表。但是，為了確保數(shù)據(jù)的一致性，Order與 OrderDetail在更新時(shí)必須在事務(wù)保護(hù)下同時(shí)進(jìn)行，即確保兩表同時(shí)更行成功。顯然它們是相互矛盾的。（此處表述有錯(cuò)誤。呂震宇 2005-6-15）

【補(bǔ)充2005-6-15】---------------------------------------------

聽棠.NET指出：主檔放在事務(wù)中提交時(shí)，通過@@IDENTITY 就可以取到生成值的，因此可以傳給明細(xì)當(dāng)外鍵用，而且在事務(wù)發(fā)生錯(cuò)誤回滾時(shí)，主檔記錄也會(huì)被回滾取消的。

呂震宇補(bǔ)充：使用自動(dòng)增長字段會(huì)增加網(wǎng)絡(luò)的roundTrip。盡管可以使用@@IDENTITY取得主鍵的值，但在更新過程中，不得不增加一次數(shù)據(jù)往返（以C/S結(jié)構(gòu)為例）：

1、客戶端發(fā)送開始事務(wù)命令
2、客戶端提交主表更新
3、服務(wù)器返回@@IDENTITY
4、客戶端根據(jù)返回的主鍵更新從表緩沖
5、客戶端將從表提交服務(wù)器更新
6、客戶端提交事務(wù)

在這里多了一次往返就會(huì)增加了事務(wù)處理的時(shí)間。降低并發(fā)性能。

如果不用自動(dòng)增長型字段，將是以下情景：

1、客戶端發(fā)送開始事務(wù)命令
2、客戶端提交主表更新
3、客戶端提交從表更新
4、客戶端提交事務(wù)

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

------------------------------------------------

除 此之外，當(dāng)我們需要在多個(gè)數(shù)據(jù)庫間進(jìn)行數(shù)據(jù)的復(fù)制時(shí)（SQL Server的數(shù)據(jù)分發(fā)、訂閱機(jī)制允許我們進(jìn)行庫間的數(shù)據(jù)復(fù)制操作），自動(dòng)增長型字段可能造成數(shù)據(jù)合并時(shí)的主鍵沖突。設(shè)想一個(gè)數(shù)據(jù)庫中的Order表向另 一個(gè)庫中的Order表復(fù)制數(shù)據(jù)庫時(shí)，OrderID到底該不該自動(dòng)增長呢？

ADO.NET允許我們?cè)贒ataSet中將某一個(gè)字段設(shè)置為自動(dòng)增長型字段，但千萬記住，這個(gè)自動(dòng)增長字段僅僅是個(gè)占位符而已，當(dāng)數(shù)據(jù)庫進(jìn)行更新 時(shí)，數(shù)據(jù)庫生成的值會(huì)自動(dòng)取代ADO.NET分配的值。所以為了防止用戶產(chǎn)生誤解，建議大家將ADO.NET中的自動(dòng)增長初始值以及增量都設(shè)置成-1。此 外，在ADO.NET中，我們可以為兩張表建立DataRelation，這樣存在級(jí)聯(lián)關(guān)系的兩張表更新時(shí)，一張表更新后另外一張表對(duì)應(yīng)鍵的值也會(huì)自動(dòng)發(fā) 生變化，這會(huì)大大減少了我們對(duì)存在級(jí)聯(lián)關(guān)系的兩表間更新時(shí)自動(dòng)增長型字段帶來的麻煩。

二、手動(dòng)增長型字段

既然自動(dòng)增長型字段會(huì)帶來如此的麻煩，我們不妨考慮使用手動(dòng)增長型的字段，也就是說主鍵的值需要自己維護(hù)，通常情況下需要建立一張單獨(dú)的表存儲(chǔ)當(dāng)前 主鍵鍵值。還用上面的例子來說，這次我們新建一張表叫IntKey，包含兩個(gè)字段，KeyName以及KeyValue。就像一個(gè)HashTable，給 一個(gè)KeyName，就可以知道目前的KeyValue是什么，然后手工實(shí)現(xiàn)鍵值數(shù)據(jù)遞增。在SQL Server中可以編寫這樣一個(gè)存儲(chǔ)過程，讓取鍵值的過程自動(dòng)進(jìn)行。代碼如下：

CREATE?PROCEDURE?[GetKey]

@KeyName?char(10),?
@KeyValue?int?OUTPUT?

AS
UPDATE?IntKey?SET?@KeyValue?=?KeyValue?=?KeyValue?+?1?WHERE?KeyName?=?@KeyName
GO

這樣，通過調(diào)用存儲(chǔ)過程，我們可以獲得最新鍵值，確保不會(huì)出現(xiàn)重復(fù)。若將OrderID字段設(shè)置為手動(dòng)增長型字段，我們的程序可以由以下幾步來實(shí) 現(xiàn)：首先調(diào)用存儲(chǔ)過程，獲得一個(gè)OrderID，然后使用這個(gè)OrderID填充Order表與OrderDetail表，最后在事務(wù)保護(hù)下對(duì)兩表進(jìn)行更 新。

使用手動(dòng)增長型字段作為主鍵在進(jìn)行數(shù)據(jù)庫間數(shù)據(jù)復(fù)制時(shí)，可以確保數(shù)據(jù)合并過程中不會(huì)出現(xiàn)鍵值沖突，只要我們?yōu)椴煌臄?shù)據(jù)庫分配不同的主鍵取值段就行 了。但是，使用手動(dòng)增長型字段會(huì)增加網(wǎng)絡(luò)的RoundTrip，我們必須通過增加一次數(shù)據(jù)庫訪問來獲取當(dāng)前主鍵鍵值，這會(huì)增加網(wǎng)絡(luò)和數(shù)據(jù)庫的負(fù)載，當(dāng)處于 一個(gè)低速或斷開的網(wǎng)絡(luò)環(huán)境中時(shí)，這種做法會(huì)有很大的弊端。同時(shí)，手工維護(hù)主鍵還要考慮并發(fā)沖突等種種因素，這更會(huì)增加系統(tǒng)的復(fù)雜程度。

三、使用UniqueIdentifier

SQL Server為我們提供了UniqueIdentifier數(shù)據(jù)類型，并提供了一個(gè)生成函數(shù)NEWID( )，使用NEWID( )可以生成一個(gè)唯一的UniqueIdentifier。UniqueIdentifier在數(shù)據(jù)庫中占用16個(gè)字節(jié)，出現(xiàn)重復(fù)的概率非常小，以至于可以 認(rèn)為是0。我們經(jīng)常從注冊(cè)表中看到類似

{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}

的東西實(shí)際上就是一個(gè)UniqueIdentifier，Windows用它來做COM組件以及接口的標(biāo)識(shí)，防止出現(xiàn)重復(fù)。在.NET里管 UniqueIdentifier稱之為GUID（Global Unique Identifier）。在C#中可以使用如下命令生成一個(gè)GUID：

Guid?u?=?System.Guid.NewGuid();

對(duì)于上面提到的Order與OrderDetail的程序，如果選用UniqueIdentifier作為主鍵的話，我們完全可以避免上面提到的增加網(wǎng)絡(luò)RoundTrip的問題。通過程序直接生成GUID填充主鍵，不用考慮是否會(huì)出現(xiàn)重復(fù)。

UniqueIdentifier字段也存在嚴(yán)重的缺陷：首先，它的長度是16字節(jié)，是整數(shù)的4倍長，會(huì)占用大量存儲(chǔ)空間。更為嚴(yán)重的 是，UniqueIdentifier的生成毫無規(guī)律可言，要想在上面建立索引（絕大多數(shù)數(shù)據(jù)庫在主鍵上都有索引）是一個(gè)非常耗時(shí)的操作。有人做過實(shí)驗(yàn)， 插入同樣的數(shù)據(jù)量，使用UniqueIdentifier型數(shù)據(jù)做主鍵要比使用Integer型數(shù)據(jù)慢，所以，出于效率考慮，盡可能避免使用 UniqueIdentifier型數(shù)據(jù)庫作為主鍵鍵值。

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

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

COMB數(shù)據(jù)類型的基本設(shè)計(jì)思路是這樣的：既然UniqueIdentifier數(shù)據(jù)因毫無規(guī)律可言造成索引效率低下，影響了系統(tǒng)的性能，那么我們 能不能通過組合的方式，保留UniqueIdentifier的前10個(gè)字節(jié)，用后6個(gè)字節(jié)表示GUID生成的時(shí)間（DateTime），這樣我們將時(shí)間 信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時(shí)增加了有序性，以此來提高索引效率。也許有人會(huì) 擔(dān)心UniqueIdentifier減少到10字節(jié)會(huì)造成數(shù)據(jù)出現(xiàn)重復(fù)，其實(shí)不用擔(dān)心，后6字節(jié)的時(shí)間精度可以達(dá)到1/300秒，兩個(gè)COMB類型數(shù)據(jù) 完全相同的可能性是在這1/300秒內(nèi)生成的兩個(gè)GUID前10個(gè)字節(jié)完全相同，這幾乎是不可能的！在SQL Server中用SQL命令將這一思路實(shí)現(xiàn)出來便是：

DECLARE?@aGuid?UNIQUEIDENTIFIER

SET?@aGuid?=?CAST(CAST(NEWID()?AS?BINARY(10))?
+?CAST(GETDATE()?AS?BINARY(6))?AS?UNIQUEIDENTIFIER)

經(jīng)過測(cè)試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類型要快上一些。關(guān)于測(cè)試數(shù)據(jù)可以參考我2004年7月21日的隨筆。

除了使用存儲(chǔ)過程實(shí)現(xiàn)COMB數(shù)據(jù)外，我們也可以使用C#生成COMB數(shù)據(jù)，這樣所有主鍵生成工作可以在客戶端完成。C#代碼如下：

//================================================================
///<summary>
///?返回?GUID?用于數(shù)據(jù)庫操作，特定的時(shí)間代碼可以提高檢索效率
///?</summary>
///?<returns>COMB?(GUID?與時(shí)間混合型)?類型?GUID?數(shù)據(jù)</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?中生成時(shí)間信息
///?</summary>
///?<param?name="guid">包含時(shí)間信息的?COMB?</param>
///?<returns>時(shí)間</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;?
}

結(jié)語

數(shù)據(jù)庫主鍵在數(shù)據(jù)庫中占有重要地位。主鍵的選取策略決定了系統(tǒng)是否高效、易用。本文比較了四種主鍵選取策略的優(yōu)缺點(diǎn)，并提供了相應(yīng)的代碼解決方案，希望對(duì)大家有所幫助。

轉(zhuǎn)載于:https://www.cnblogs.com/ylqmf/archive/2011/10/11/2207228.html

總結(jié)

以上是生活随笔為你收集整理的小议数据库主键选取策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。