佳木斯湛栽影视文化发展公司

主頁(yè) > 知識(shí)庫(kù) > 小議sqlserver數(shù)據(jù)庫(kù)主鍵選取策略

小議sqlserver數(shù)據(jù)庫(kù)主鍵選取策略

熱門(mén)標(biāo)簽:呼叫中心市場(chǎng)需求 AI電銷(xiāo) 鐵路電話系統(tǒng) 百度競(jìng)價(jià)排名 服務(wù)外包 網(wǎng)站排名優(yōu)化 地方門(mén)戶網(wǎng)站 Linux服務(wù)器
因?yàn)橹麈I可以唯一標(biāo)識(shí)某一行記錄,所以可以確保執(zhí)行數(shù)據(jù)更新、刪除的時(shí)候不會(huì)出現(xiàn)張冠李戴的錯(cuò)誤。當(dāng)然,其它字段可以輔助我們?cè)趫?zhí)行這些操作時(shí)消除共享沖突,不過(guò)就不在這里討論了。主鍵除了上述作用外,常常與外鍵構(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
“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)
Order表中的OrderID是自動(dòng)增長(zhǎng)型的字段?,F(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表。最后更新OderDetail表。但是,為了確保數(shù)據(jù)的一致性,Order與 OrderDetail在更新時(shí)必須在事務(wù)保護(hù)下同時(shí)進(jìn)行,即確保兩表同時(shí)更行成功。顯然它們是相互矛盾的。(此處表述有錯(cuò)誤。呂震宇 2005-6-15)
【補(bǔ)充2005-6-15】---------------------------------------------
聽(tīng)棠.NET指出:主檔放在事務(wù)中提交時(shí),通過(guò)@@IDENTITY 就可以取到生成值的,因此可以傳給明細(xì)當(dāng)外鍵用,而且在事務(wù)發(fā)生錯(cuò)誤回滾時(shí),主檔記錄也會(huì)被回滾取消的。
呂震宇補(bǔ)充:使用自動(dòng)增長(zhǎng)字段會(huì)增加網(wǎng)絡(luò)的roundTrip。盡管可以使用@@IDENTITY取得主鍵的值,但在更新過(guò)程中,不得不增加一次數(shù)據(jù)往返(以C/S結(jié)構(gòu)為例):
1、客戶端發(fā)送開(kāi)始事務(wù)命令
2、客戶端提交主表更新
3、服務(wù)器返回@@IDENTITY
4、客戶端根據(jù)返回的主鍵更新從表緩沖
5、客戶端將從表提交服務(wù)器更新
6、客戶端提交事務(wù)
在這里多了一次往返就會(huì)增加了事務(wù)處理的時(shí)間。降低并發(fā)性能。
如果不用自動(dòng)增長(zhǎng)型字段,將是以下情景:
1、客戶端發(fā)送開(kāi)始事務(wù)命令
2、客戶端提交主表更新
3、客戶端提交從表更新
4、客戶端提交事務(wù)
因此我不贊成使用自動(dòng)增長(zhǎng)型字段作為主鍵與外鍵鏈接的紐帶。
------------------------------------------------
除此之外,當(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í)的主鍵沖突。設(shè)想一個(gè)數(shù)據(jù)庫(kù)中的Order表向另一個(gè)庫(kù)中的Order表復(fù)制數(shù)據(jù)庫(kù)時(shí),OrderID到底該不該自動(dòng)增長(zhǎng)呢?
ADO.NET允許我們?cè)贒ataSet中將某一個(gè)字段設(shè)置為自動(dòng)增長(zhǎng)型字段,但千萬(wàn)記住,這個(gè)自動(dòng)增長(zhǎng)字段僅僅是個(gè)占位符而已,當(dāng)數(shù)據(jù)庫(kù)進(jìn)行更新時(shí),數(shù)據(jù)庫(kù)生成的值會(huì)自動(dòng)取代ADO.NET分配的值。所以為了防止用戶產(chǎn)生誤解,建議大家將ADO.NET中的自動(dòng)增長(zhǎ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)增長(zhǎng)型字段帶來(lái)的麻煩。
二、手動(dòng)增長(zhǎng)型字段
既然自動(dòng)增長(zhǎng)型字段會(huì)帶來(lái)如此的麻煩,我們不妨考慮使用手動(dòng)增長(zhǎng)型的字段,也就是說(shuō)主鍵的值需要自己維護(hù),通常情況下需要建立一張單獨(dú)的表存儲(chǔ)當(dāng)前主鍵鍵值。還用上面的例子來(lái)說(shuō),這次我們新建一張表叫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)行。代碼如下:
復(fù)制代碼 代碼如下:

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ù)保護(hù)下對(duì)兩表進(jìn)行更新。
使用手動(dòng)增長(zhǎng)型字段作為主鍵在進(jìn)行數(shù)據(jù)庫(kù)間數(shù)據(jù)復(fù)制時(shí),可以確保數(shù)據(jù)合并過(guò)程中不會(huì)出現(xiàn)鍵值沖突,只要我們?yōu)椴煌臄?shù)據(jù)庫(kù)分配不同的主鍵取值段就行了。但是,使用手動(dòng)增長(zhǎng)型字段會(huì)增加網(wǎng)絡(luò)的RoundTrip,我們必須通過(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ù)的概率非常小,以至于可以認(rèn)為是0。我們經(jīng)常從注冊(cè)表中看到類(lèi)似
{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ī)律可言,要想在上面建立索引(絕大多數(shù)數(shù)據(jù)庫(kù)在主鍵上都有索引)是一個(gè)非常耗時(shí)的操作。有人做過(guò)實(shí)驗(yàn),插入同樣的數(shù)據(jù)量,使用UniqueIdentifier型數(shù)據(jù)做主鍵要比使用Integer型數(shù)據(jù)慢,所以,出于效率考慮,盡可能避免使用 UniqueIdentifier型數(shù)據(jù)庫(kù)作為主鍵鍵值。
四、使用“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)便是:
復(fù)制代碼 代碼如下:

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)型要快上一些。關(guān)于測(cè)試數(shù)據(jù)可以參考我2004年7月21日的隨筆。
除了使用存儲(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;
}

結(jié)語(yǔ)
數(shù)據(jù)庫(kù)主鍵在數(shù)據(jù)庫(kù)中占有重要地位。主鍵的選取策略決定了系統(tǒng)是否高效、易用。本文比較了四種主鍵選取策略的優(yōu)缺點(diǎn),并提供了相應(yīng)的代碼解決方案,希望對(duì)大家有所幫助。
您可能感興趣的文章:
  • SQLServer主鍵和唯一約束的區(qū)別
  • 如何獲取SqlServer2005表結(jié)構(gòu)(字段,主鍵,外鍵,遞增,描述)
  • 深入Mysql,SqlServer,Oracle主鍵自動(dòng)增長(zhǎng)的設(shè)置詳解
  • SQLSERVER聚集索引和主鍵(Primary Key)的誤區(qū)認(rèn)識(shí)
  • sqlserver主鍵設(shè)計(jì)的注意點(diǎn)
  • sqlserver數(shù)據(jù)庫(kù)主鍵的生成方式小結(jié)(sqlserver,mysql)
  • sqlserver主鍵自增的實(shí)現(xiàn)示例

標(biāo)簽:湘潭 黃山 蘭州 衡水 湖南 銅川 仙桃 崇左

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《小議sqlserver數(shù)據(jù)庫(kù)主鍵選取策略》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266
    阜城县| 平舆县| 凤城市| 东台市| 茌平县| 永济市| 吉安县| 千阳县| 大关县| 海安县| 丹巴县| 酉阳| 忻州市| 中方县| 高清| 霍邱县| 临夏县| 织金县| 亚东县| 安徽省| 方山县| 遵义市| 富宁县| 登封市| 奈曼旗| 会泽县| 崇州市| 嵊泗县| 英吉沙县| 三原县| 淮安市| 美姑县| 湖口县| 板桥市| 广昌县| 金昌市| 湖南省| 红河县| 澳门| 广汉市| 朔州市|