1.是否要采用GUID作為主鍵

用GUID作主鍵有它的優勢與不足.優勢是GUID具有唯一性,在任何情況下,可以產生全球唯一的值.這是GUID最大的優勢,也方便數據導入,比如要求從另一個系統中把數據導入進來,那么,不用擔心,導入時,會導致主鍵沖突.不足是GUID值太復雜.不易記憶,因為有時,難免我們會用記錄的方式,來進行記錄判斷.而且數據太長,影響數據庫效率.GUID的產生不是以一定的次序產生,對于按主鍵物理排序的數據庫來說,如果在記錄的前部插入一條記錄,可能會導致后面N次方的數據條數后移.這將導致數據插入效率.因此GUID的采用應該要慎重.

2.是否要采用自動遞增的方式

對于以前談到的主鍵,要求唯一性,因此大家都用自動遞增的方式.這樣的方式是非常不可取的.可能是為了方便插入記錄時,不必去人為創建主鍵值.以為這樣會方便,其實不是的.帶來的麻煩要遠遠勝于這種所謂的"方便".第一:數據導入不方便,經常會有從另一系統導入數據進來,自動遞增的主鍵,將不允許原表中的ID被導入進來.這會導致主鍵丟失.第二:對于象訂單這樣的有主外鍵的表來說,如果訂單的"主檔表"主鍵是自動生成的.那么在保存一個訂單時,會要求對主檔表與明細表同進行事務保存,而此時,先要生成一條訂單,然后取出這個訂單自動生成的主鍵,然后再把此作為明細表的一個外鍵,進行明細的保存.這過程中,將變以復雜而且不可行.事務如何處理.訂單主檔表插入記錄后,要是明細保存時遇到錯誤,主檔表記錄還要進行刪除.煩.插入成功以后,還要取出產生的最大值.這將是一個嚴重的浪費.記錄多的話會影響速度,而且會存在并行插入.導致獲取的記錄可能是不正確的. 因此在以上的嚴重問題下,請不要采用自動遞增方式.

3.是否要采用int型作為主鍵

以前大家都采用int型，都是出來主鍵都是數字導致的．其實我們也明白．并不是只是數字的東西就是數字型的．比如電話號碼等．因此對于主鍵，采用int型的優勢是速度快，插入，查詢時都可能會比其他的方式快．但我這種快的效果也未必有多明顯，比如以varchar(15)為例，物理主鍵排序的數據，會自動以主鍵進行物理數據排序．因此，就算是字符型的數據，在插入時也會插入到相應的物理位置上，也就是說，在插入時可能會影響一些速度．但在以后的查詢中，速度影響不會太明顯．而我要說的，不采用int型作為主鍵，不是說，里面不存數據．我還是建議大家在主鍵中存放數字，這樣的排序比較要比夾雜字母的排序來的快，之所以要采用字符型，也是為以后的數據導入作準備，有一天，會要求從其他表導入數據時，可以在導入數據的主鍵上加一個特定字母來避免與原主鍵沖突．比如在導入數據的主鍵前加一個＂Ｎ＂字母．這也就不用擔心，要求導入數據表中的主鍵是數字型還是字符型了．

４．是否采用編號來定義主鍵

這個問題是老生常談了．主鍵設計有個原則，就是主鍵不應具有任何實際意義．這條其實是非常重要，有人就是覺得編號本身是唯一的，可以作為主鍵用，但可能會為以后帶來麻煩．因為帶有實際意義的字段，還是存在被修改的可能性．而對于主鍵最大的忌諱就是修改主鍵，這可能會導致非常嚴重的不可估計的后果．比如學生編號，平時以為永遠不會修改，但修改的可能還是會存在．

還有一種，表面上是唯一的，但實際上應該是允許重復的．我舉個例子，訂單吧，訂單編號應該是唯一吧．是的．可是會存在這樣的情況，一張原來的訂單是因為某個原因，要求訂單作廢．那好給訂單的狀態標識為＂cancel＂．然后允許再次錄入同樣編號的訂單．因此．對于這樣的情況下在，雖然有效的訂單編號只有一個，但在數據庫角度會允許編號重復．所以不管如何，還是建議大家為表都建一個沒有任何意義的主鍵，如ＩＤ．

因此，總結一下，我在設計主鍵，會采用字符型的．不采用自動遞增，在新增記錄時，系統生成主鍵值．一般為全數字進行存入，至于主鍵值的生成規則，可以按需求進行規則定義．如果沒有特殊的要求，只是為了保持唯一，可以定義一個字段存放一個數值．在生成時，自動加一．然后再存回去．這也比從一個表中尋找最大值要來的快吧．

轉載于:https://www.cnblogs.com/wala-wo/archive/2012/02/16/5119485.html

總結

以上是生活随笔為你收集整理的主键设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。