關(guān)系型數(shù)據(jù)庫(kù)主鍵總結(jié)

在基于關(guān)系型數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)候，通常要為每張表指定一個(gè)主鍵，所謂主鍵就是能夠唯一標(biāo)識(shí)表中某一行記錄的屬性或?qū)傩越M，一個(gè)表只能有一個(gè)主鍵，但可以 有多個(gè)候選索引。因?yàn)橹麈I可以唯一標(biāo)識(shí)某一行記錄，所以可以確保執(zhí)行數(shù)據(jù)更新、刪除、修改時(shí)不出現(xiàn)錯(cuò)誤。當(dāng)然，其它字段可以輔助我們?cè)趫?zhí)行這些操作時(shí)消除 共享沖突，不是本文討論的重點(diǎn)，不再贅述。主鍵除了上述作用外，常常與外鍵構(gòu)成參照完整性約束，防止出現(xiàn)數(shù)據(jù)不一致。所以數(shù)據(jù)庫(kù)在設(shè)計(jì)時(shí)，主鍵起到了很重 要的作用。常見(jiàn)的數(shù)據(jù)庫(kù)主鍵選取方式有： 自動(dòng)增長(zhǎng)式、手動(dòng)增長(zhǎng)式 、UniqueIdentifier、聯(lián)合式（復(fù)合式）、時(shí)間序列+隨機(jī)數(shù)式、“COMB（Combine）”類(lèi)型。
一、自動(dòng)增長(zhǎng)式
很多數(shù)據(jù)庫(kù)設(shè)計(jì)者喜歡使用自動(dòng)增長(zhǎng)型字段，因?yàn)樗褂煤?jiǎn)單。自動(dòng)增長(zhǎng)式允許我們?cè)谙驍?shù)據(jù)庫(kù)添加數(shù)據(jù)時(shí)，不考慮主鍵的取值，記錄插入后，數(shù)據(jù)庫(kù)系統(tǒng)會(huì) 自動(dòng)為其分配一個(gè)值，確保絕對(duì)不會(huì)出現(xiàn)重復(fù)。如果使用SQL Server數(shù)據(jù)庫(kù)的話，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統(tǒng)分配的主鍵值。?
盡管自動(dòng)增長(zhǎng)式字段會(huì)省掉我們很多繁瑣的工作，但使用它也存在潛在的問(wèn)題，那就是在數(shù)據(jù)緩沖模式下，很難預(yù)先填寫(xiě)主鍵與外鍵的值。假設(shè)有主輔兩張表：
Order(OrderID, OrderDate)? 訂單表
OrderDetial(OrderID, LineNum, ProductID, Price)? 訂單明細(xì)表
Order 表中的OrderID是自動(dòng)增長(zhǎng)型的字段。假設(shè)現(xiàn)在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條 記錄。因?yàn)镺rder表中的OrderID是自動(dòng)增長(zhǎng)型的字段，那么我們?cè)谟涗浾讲迦氲綌?shù)據(jù)庫(kù)之前無(wú)法事先得知它的取值，只有在更新后才能知道數(shù)據(jù)庫(kù)為 它分配的是什么值。這會(huì)造成以下矛盾發(fā)生：?
首先，為了能在OrderDetail的OrderID字段中添入正確的值，必須先更新 Order表以獲取到系統(tǒng)為其分配的OrderID值，然后再用這個(gè)OrderID填充OrderDetail表的OrderID列。最后更新 OderDetail表。但是，為了確保數(shù)據(jù)的一致性，Order與OrderDetail在更新時(shí)必須在事務(wù)模式下進(jìn)行的，即要么兩張表同時(shí)同時(shí)更新成 功、要么全部失敗，顯然它們是相互矛盾的。?
?其次，當(dāng)我們需要在多個(gè)數(shù)據(jù)庫(kù)間進(jìn)行數(shù)據(jù)的復(fù)制時(shí)（SQL Server的數(shù)據(jù)分發(fā)、訂閱機(jī)制允許我們進(jìn)行庫(kù)間的數(shù)據(jù)復(fù)制操作），自動(dòng)增長(zhǎng)式字段可能造成數(shù)據(jù)合并時(shí)的主鍵沖突及表關(guān)聯(lián)關(guān)系的丟失。設(shè)想一個(gè)數(shù)據(jù)庫(kù)中 的Order表向另一個(gè)庫(kù)中的Order表復(fù)制數(shù)據(jù)庫(kù)時(shí)，OrderID到底該不該自動(dòng)增長(zhǎng)呢？如果自動(dòng)增長(zhǎng)，其子表OrderDetial的關(guān)聯(lián)關(guān)系會(huì) 丟失，如果不增長(zhǎng)就會(huì)和現(xiàn)有數(shù)據(jù)主鍵重復(fù)，是不是很矛盾呢？?
再次，自增量的值都是需要在系統(tǒng)中維護(hù)一個(gè)全局的數(shù)據(jù)值，每次插入數(shù)據(jù)時(shí)即對(duì)此次值進(jìn)行增量取值。當(dāng)在產(chǎn)生唯一標(biāo)識(shí)的并發(fā)環(huán)境中，每次的增量取值都必須為此全局值加鎖解鎖以保證增量的唯一性。造成并發(fā)瓶頸，降低查詢性能。
??? 還有當(dāng)數(shù)據(jù)表足夠大或頻繁的更改和插入操作導(dǎo)致主鍵類(lèi)型值超出范圍，這種情況一般很少碰到，但也是我們進(jìn)行數(shù)據(jù)表設(shè)計(jì)時(shí)必須考慮的一個(gè)問(wèn)題

在實(shí)際開(kāi)發(fā)中中容易出現(xiàn)主鍵沖突 主鍵沖突就是主鍵出現(xiàn)重復(fù)值
比如 t_user t_admin 都有主鍵 都是id 自增方式
Insert into t_user (id)
Select id from t_admin
兩表中都有主鍵為 7的時(shí)候 插入數(shù)據(jù)不成功 因?yàn)橹麈I沖突
解決辦法
UPDATE t_admin SET id=-id
WHERE id IS NOT NULL AND id>0

Commit;

二、手動(dòng)增長(zhǎng)型字段
既然自動(dòng)增長(zhǎng)型字段會(huì)帶來(lái)如此的麻煩，我們不妨考慮使用手動(dòng)增長(zhǎng)型的字段，也就是說(shuō)主鍵的值需要自己維護(hù)，通常情況下需要建立一張單獨(dú)的表存儲(chǔ)當(dāng)前 主鍵鍵值。為了敘述上的方便仍然利用上面的例子進(jìn)行闡述，新建一張表叫IntKey，包含兩個(gè)字段，KeyName以及KeyValue。就像一個(gè) HashTable，給一個(gè)KeyName，就可以知道目前的KeyValue是什么，然后手工實(shí)現(xiàn)鍵值數(shù)據(jù)遞增。在SQL Server中可以編寫(xiě)這樣一個(gè)存儲(chǔ)過(guò)程，讓取鍵值的過(guò)程自動(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
這樣，通過(guò)調(diào)用存儲(chǔ)過(guò)程，我們可以獲得最新鍵值，確保不會(huì)出現(xiàn)重復(fù)。若將OrderID字段設(shè)置為手動(dòng)增長(zhǎng)式字段，我們的程序可以由以下幾步來(lái)實(shí) 現(xiàn)：首先調(diào)用存儲(chǔ)過(guò)程，獲得一個(gè)OrderID，然后使用這個(gè)OrderID填充Order表與OrderDetail表，最后在事務(wù)機(jī)制下對(duì)兩表進(jìn)行更 新。?
使用手動(dòng)增長(zhǎng)式字段作為主鍵在進(jìn)行數(shù)據(jù)庫(kù)間數(shù)據(jù)復(fù)制時(shí)，可以確保數(shù)據(jù)合并過(guò)程中不會(huì)出現(xiàn)鍵值沖突，只要為不同的數(shù)據(jù)表分配不同的主鍵取值段 就行了。但是，使用手動(dòng)增長(zhǎng)型字段會(huì)增加網(wǎng)絡(luò)的負(fù)擔(dān)，必須通過(guò)增加一次數(shù)據(jù)庫(kù)訪問(wèn)來(lái)獲取當(dāng)前主鍵鍵值，這會(huì)增加網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)的負(fù)載，當(dāng)處于一個(gè)低速或斷開(kāi) 的網(wǎng)絡(luò)環(huán)境中時(shí)，這種做法會(huì)有很大的弊端。同時(shí)，手工維護(hù)主鍵還要考慮并發(fā)沖突等種種因素，這更會(huì)增加系統(tǒng)的復(fù)雜程度。
三、使用UniqueIdentifier
SQL Server為我們提供了UniqueIdentifier數(shù)據(jù)類(lèi)型，并提供了一個(gè)生成函數(shù)NEWID( )，使用NEWID( )可以生成一個(gè)唯一的UniqueIdentifier。UniqueIdentifier在數(shù)據(jù)庫(kù)中占用16個(gè)字節(jié)，出現(xiàn)重復(fù)的概率幾乎為0，號(hào)稱全球 唯一標(biāo)識(shí)。我們經(jīng)常從注冊(cè)表或WINDOWS程序出現(xiàn)錯(cuò)誤需要調(diào)試時(shí)看到類(lèi)似 768427bf-9b37-4776-97ca-000365e160d5或{45F0EB02-0727-4F2E-AAB5- E8AEDEE0CEC5} 的東西實(shí)際上就是一個(gè)UniqueIdentifier，Windows用它來(lái)做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的問(wèn)題。通過(guò)程序直接生成GUID填充主鍵，不用考慮是否會(huì)出現(xiàn)重復(fù)。 但是UniqueIdentifier 字段也存在嚴(yán)重的缺陷：首先，它的長(zhǎng)度是16字節(jié)，是整數(shù)的4倍長(zhǎng)，會(huì)占用大量存儲(chǔ)空間。更為嚴(yán)重的是，UniqueIdentifier的生成毫無(wú)規(guī)律 可言，也就是說(shuō)是無(wú)序的，要想在上面建立索引（絕大多數(shù)數(shù)據(jù)庫(kù)在主鍵上都有索引）是一個(gè)非常耗時(shí)的操作。有人做過(guò)實(shí)驗(yàn)，當(dāng)數(shù)據(jù)表記錄比較大的時(shí)，在不同的 數(shù)據(jù)量級(jí)別上插入同樣的數(shù)據(jù)量，使用 UniqueIdentifier型數(shù)據(jù)做主鍵要比使用Integer型數(shù)據(jù)慢，且還沒(méi)有考慮到表關(guān)聯(lián)的情況，出于效率考慮，盡可能避免使用 UniqueIdentifier型數(shù)據(jù)庫(kù)作為主鍵值，但隨著現(xiàn)代計(jì)算機(jī)計(jì)算速度越來(lái)越快，在中小型項(xiàng)目中使用UniqueIdentifier式主鍵也 是一個(gè)選項(xiàng)。
四、使用業(yè)務(wù)字段聯(lián)合主鍵
????
基于DEPHI和 POWERBUILDER等數(shù)據(jù)庫(kù)工具開(kāi)發(fā)C/S系統(tǒng)的數(shù)據(jù)庫(kù)設(shè)計(jì)人員，習(xí)慣上用有業(yè)務(wù)意義的字段組合成復(fù)合主鍵做數(shù)據(jù)表主鍵。使用業(yè)務(wù)主鍵當(dāng)然有其與生 俱來(lái)的好處，一般情況下數(shù)據(jù)庫(kù)系統(tǒng)會(huì)在默認(rèn)條件下建立聚簇索引，而且這個(gè)聚簇索引基于主鍵升序排列，當(dāng)數(shù)據(jù)量比較小時(shí)，我們感覺(jué)不到這種差別，當(dāng)數(shù)據(jù)量比 較大時(shí)，這種基于主鍵定義的聚簇索引的優(yōu)勢(shì)就顯現(xiàn)出來(lái)，這就使得數(shù)據(jù)表在每次存取數(shù)據(jù)時(shí)按照索引準(zhǔn)確確認(rèn)數(shù)據(jù)插入或更新的磁盤(pán)物理位置，減少磁頭尋址時(shí) 間，從而提高數(shù)據(jù)庫(kù)性能，而且能夠從業(yè)務(wù)意義上保證數(shù)據(jù)的完整性，增加程序的可靠性。但是基于業(yè)務(wù)字段的聯(lián)合索引，當(dāng)業(yè)務(wù)字段選用比較多時(shí)會(huì)占用比較多的 磁盤(pán)空間，而且索引頁(yè)會(huì)占用更多的內(nèi)存頁(yè)面，從而導(dǎo)致查詢命中率降低；另外使用業(yè)務(wù)主鍵，當(dāng)涉及到主鍵數(shù)據(jù)的修改時(shí)，要在編程過(guò)程中記錄新值和原值的關(guān)系 表，在更新時(shí)又要進(jìn)行新值和原值的比對(duì)，增加編寫(xiě)程序的復(fù)雜度。
五、時(shí)間序列+隨機(jī)數(shù)主鍵
采用精確到毫秒甚至鈉秒級(jí)的時(shí)間和一個(gè)隨機(jī)產(chǎn)生的兩位數(shù)做主鍵，如200911282311528+兩位隨機(jī)數(shù)，不失為解決主鍵問(wèn)題的一個(gè)有效辦 法。這樣產(chǎn)生的主鍵既避免了UniqueIdentifier型字段做主鍵時(shí)的無(wú)序，又能有效避免自動(dòng)增長(zhǎng)型主鍵帶來(lái)的諸如復(fù)制和數(shù)據(jù)導(dǎo)入的麻煩。但在使 用用戶眾多的網(wǎng)絡(luò)實(shí)時(shí)系統(tǒng)中，在時(shí)間和空間上仍然不能保證唯一性的問(wèn)題。
六、使用“COMB（Combine）”類(lèi)型
既然上面五種主鍵類(lèi)型選取策略都存在各自的缺點(diǎn)，那么到底有沒(méi)有好的辦法加以解決呢？答案是肯定的。通過(guò)使用COMB類(lèi)型（數(shù)據(jù)庫(kù)中沒(méi)有COMB類(lèi) 型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設(shè)計(jì)出來(lái)的），可以在以上眾多的主鍵策略之間采用中庸之道，找到一個(gè)很好的平衡點(diǎn)。
COMB數(shù)據(jù)類(lèi)型的基本設(shè)計(jì)思路是這樣的：既然UniqueIdentifier數(shù)據(jù)因毫無(wú)規(guī)律可言造成索引效率低下，影響了系統(tǒng)的性能，那么我們 能不能通過(guò)組合的方式，保留UniqueIdentifier的前10個(gè)字節(jié)，用后6個(gè)字節(jié)表示GUID生成的時(shí)間（DateTime），這樣我們將時(shí)間 信息與 UniqueIdentifier組合起來(lái)，在保留UniqueIdentifier的唯一性的同時(shí)增加了有序性，以此來(lái)提高索引效率。也許有人會(huì)擔(dān)心 UniqueIdentifier減少到10字節(jié)會(huì)造成數(shù)據(jù)出現(xiàn)重復(fù)，其實(shí)不用擔(dān)心，后6字節(jié)的時(shí)間精度可以達(dá)到1/300秒，兩個(gè)COMB類(lèi)型數(shù)據(jù)完全 相同的可能性是在這1/300秒內(nèi)生成的兩個(gè)GUID前10個(gè)字節(jié)完全相同，這幾乎是不可能的！在SQL Server中用SQL命令將這一思路實(shí)現(xiàn)出來(lái)便是：
DECLARE @aGuid UNIQUEIDENTIFIER?
SET @aGuid = CAST(CAST(NEWID() AS BINARY(10))?

• CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)
  經(jīng)過(guò)測(cè)試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類(lèi)型要快上一些。除了使用存儲(chǔ)過(guò)程實(shí)現(xiàn)COMB數(shù)據(jù)外，我們也可以使用C#生成COMB數(shù)據(jù)，這樣所有主鍵生成工作可以在客戶端完成。
  C#代碼如下：?
  復(fù)制代碼代碼如下:

//================================================?
/////<summary>?
/// 返回 GUID 用于數(shù)據(jù)庫(kù)操作，特定的時(shí)間代碼可以提高檢索效率?
/// </summary>?
/// <returns>COMB (GUID 與時(shí)間混合型) 類(lèi)型 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;?
}?
綜上述六種主鍵選取策略，我認(rèn)為使用“COMB（Combine）”類(lèi)型做主鍵是比較恰當(dāng)?shù)闹麈I應(yīng)用策略，但在實(shí)際使用過(guò)程中要根據(jù)客觀實(shí)踐、因時(shí)因事選取適當(dāng)?shù)闹麈I，切不可生搬硬套、弄巧成拙。