資料庫主鍵生成策略

2022-03-22 08:06:45 字數 1394 閱讀 7858

在建立資料庫的時候,需要為每張表指定乙個主鍵,所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組,乙個表只能有乙個主鍵,但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄,所以可以確保執行資料更新、刪除的時候不會出現張冠李戴的錯誤。資料庫的主鍵生成有多種方式,每種方式都有其優點和缺點,應該根據不同的需求在主鍵的時間和空間效率上做平衡折中,從而選擇不同的主鍵生成策略。歸納起來,對主鍵的選擇主要有以下四種方式:

自動增長字段

自動增長型字段允許我們在向資料庫新增資料時,不考慮主鍵的取值,記錄插入後,資料庫系統會自動為其分配乙個值,確保絕對不會出現重複。

手動增長字段

手動增長型的字段,也就是說主鍵的值需要自己維護,通常情況下需要建立一張單獨的表儲存當前主鍵鍵值。

guid型別

guid是globally unique identifier的縮寫,是乙個128位的隨機數,並保證不產生重複。

comb型別

comb(combine)型可以理解為一種改進的guid,它通過組合guid和系統時間,以使其在索引和檢索事有更優的效能。 

下表列出四種主鍵生成方式優缺點的比較:

主鍵生成策略

優點缺點

自動增長字段

使用簡單

不同資料庫獲取當前值方式不同;

難以應用在多個資料庫間進行資料遷移的情況。

手動增長型字段

可以獲得最新鍵值

可以確保資料合併過程中不會出現鍵值衝突

通常情況下需要建立一張單獨的表儲存當前主鍵鍵值;

增加一次資料庫訪問來獲取當前主鍵鍵值;

考慮併發衝突等,增加系統的複雜程度。

使用guid

直接生成guid,獲得最新鍵值以填充主鍵,使用方便;

可以確保資料合併過程中不會出現鍵值衝突;

避免了前兩種方式獲取當前鍵值所增加的開銷。

占用較多儲存空間;

索引耗時;

在多表鏈結查詢時效率不如int型

使用「comb」型別

保留guid的已有優點;

利用時間資訊與guid組合起來,增加有序性以提高索引效率。

需要設計comb的生成演算法;

和guid一樣占用較多儲存空間;

在多表鏈結查詢時效率不如int型,但優於guid。

comb型別主鍵生成實現:

comb資料型別的基本設計思路是這樣的:既然guid資料因毫無規律可言造成索引效率低下,影響了系統的效能,那麼能不能通過組合的方式,保留guid的10個位元組,用另6個位元組表示guid生成的時間(datetime),這樣我們將時間資訊與guid組合起來,在保留guid的唯一性的同時增加了有序性,以此來提高索引效率。

在nhibernate中,comb型主鍵的生成**如下所示:

public guid generatecomb()

資料庫主鍵生成策略

在建立資料庫的時候,需要為每張表指定乙個主鍵,所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組,乙個表只能有乙個主鍵,但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄,所以可以確保執行資料更新 刪除的時候不會出現張冠李戴的錯誤。資料庫的主鍵生成有多種方式,每種方式都有其優點和缺點,應該根據不同的...

mysql的主鍵策略 談資料庫主鍵選取策略

int和guid,究竟選誰?如小標題,如果真要選,我會選誰?肯定地說,我會選guid,又或者兩者都選上。後者情形下,使用guid做主鍵 int做小二,int在業務層生成,這要即使重複了,也不礙事,且int是要反饋給前端的,定時做乙個防衝突檢測。如果讓使用者記憶或反饋那guid字串 去連線字元後32位...

談資料庫主鍵選取策略

int和guid,究竟選誰?關於資料庫主鍵的選取策略,大家都是在int和guid兩者中徘徊。忘了那些喋喋不休的爭論吧!畢竟魚與熊掌,不可兼得。在這篇文章中,我們不再關注它們的優缺點,自覺先行做點功課哦!如小標題,如果真要選,我會選誰?肯定地說,我會選guid,又或者兩者都選上。後者情形下,使用gui...