主鍵設計原則

1.是否要採用guid作為主鍵

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

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

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

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

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

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

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

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

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

主鍵設計原則

MySQL 主鍵設計原則

msyql中主鍵設計原則

資料庫主鍵設計原則

主鍵設計原則

MySQL 主鍵設計原則

msyql中主鍵設計原則

資料庫主鍵設計原則

相關推薦