資料庫主鍵設計

< DOCTYPE html PUBLIC -WCDTD XHTML StrictEN httpwwwworgTRxhtmlDTDxhtml-strictdtd>

　主鍵的必要性:   

有些朋友可能不提倡資料庫表必須要主鍵，但在我的思考中，覺得每個表都應該具有主鍵，不管是單主鍵還是雙主鍵，主鍵的存在就代表着表結構的完整性，表的記錄必須得有唯一區分的字段，主鍵主要是用于其他表的外鍵關聯，本記錄的修改與删除，當我們沒有主鍵時，這些操作會變的非常麻煩。   

主鍵的無意義性： 

我強調主鍵不應該具有實際的意義，這可能對于一些朋友來說不太認同，比如訂單表吧，會有“訂單編号”字段，而這個字段呢在業務實際中本身就是應該具有唯一性，具有唯一辨別記錄的功能，但我是不推薦采用訂單編号字段作為主鍵的，因為具有實際意義的字段，具有“意義更改”的可能性，比如訂單編号在剛開始的時候我們一切順利，後來客戶說“訂單可以廢棄，并重新生成訂單，而且訂單号要保持原訂單号一緻”，這樣原來的主鍵就面臨危險了。是以，具有唯一性的實際字段也代表可以作為主鍵。是以，我推薦是新設一個字段專門用為主鍵，此主鍵本身在業務邏輯上不展現，不具有實際意義。而這種主鍵在一定程式增加了複雜度，是以要視實際系統的規模大小而定，對于小項目，以後擴充不會很大的話，也查允許用實際唯一的字段作主鍵的。   

主鍵的選擇 

我們現在在思考一下，應該采用什麼來作表的主鍵比較合理，申明一下，主鍵的設計沒有一個定論，各人有各人的方法，哪怕同一個，在不同的項目中，也會采用不同的主鍵設計原則。 

第一：編号作主鍵   

此方法就是采用實際業務中的唯一字段的“編号”作為主鍵設計，這在小型的項目中是推薦這樣做的，因為這可以使項目比較簡單化，但在使用中卻可能帶來一些麻煩，比如要進行“編号修改”時，可能要涉及到很多相關聯的其他表，就象黎叔說的“後果很嚴重”;還有就是上面提到的“業務要求允許編号重複時”，我們再那麼先知，都無法知道業務将會修改成什麼?   

第二：自動編号主鍵   

這種方法也是很多朋友在使用的，就是建立一個ID字段，自動增長，非常友善也滿足主鍵的原則，優點是：資料庫自動編号，速度快，而且是增量增長，聚集型主鍵按順序存放，對于檢索非常有利;數字型的，占用空間小，易排序，在程式中傳遞也友善;如果通過非系統增加記錄（比如手動錄入，或是用其他工具直接在表裡插入新記錄，或老系統資料導入）時，非常友善，不用擔心主鍵重複問題。   

缺點：其實缺點也就是來自其優點，就是因為自動增長，在手動要插入指定ID的記錄時會顯得麻煩，尤其是當系統與其他系統內建時，需要資料導入時，很難保證原系統的ID不發生主鍵沖突（前提是老系統也是數字型的）;如果其他系統主鍵不是數字型那就麻煩更大了，會導緻修改主鍵資料類型了，這也會導緻其他相關表的修改，後果同樣很嚴重;就算其他系統也是數字型的，在導入時，為了區分新老資料，可能想在老資料主鍵前統一加一個“o”(old)來表示這是老資料，那麼自動增長的數字型又面臨一個挑戰。   

第三：Max加一   

由于自動編号存在那些問題，是以有些朋友就采用自己生成，同樣是數字型的，隻是把自動增長去掉了，采用在Insert時，讀取Max值後加一，這種方法可以避免自動編号的問題，但也存在一個效率問題，如果記錄非常大的話，那麼Max()也會影響效率的;更嚴重的是并發性問題，如果同時有兩人讀到相同的Max後，加一後插入的ID值會重複，這已經是有經驗教訓的了。   

第四：自制加一   

考慮Max加一的效率後，有人采用自制加一，也就是建一個特别的表，字段為：表名，目前序列值。這樣在往表中插入值時，先從此表中找到相應表的最大值後加一，進行插入，有人可能發現，也可能會存在并發處理，這個并發處理，我們可以采用lock線程的方式來避免，在生成此值的時，先Lock，取到值以後，再unLock出來，這樣不會有兩人同時生成了。這比Max加一的速度要快多了。但同樣存在一個問題：在與其他系統內建時，脫離了系統中的生成方法後，很麻煩保證自制表中的最大值與導入後的保持一緻，而且數字型都存在上面講到的“o”老資料的導入問題。是以在“自制加一”中可以把主鍵設為字元型的。字元型的自制加一我倒是蠻推薦的，應該字元型主鍵可以應付很多我們意想不到的情況。 

第五：GUID主鍵   

目前一個比較好的主鍵是采用GUID，當然我是推薦主鍵還是字元型的，但值由GUID生成，GUID是可以自動生成，也可以程式生成，而且鍵值不可能重複，可以解決系統內建問題，幾個系統的GUID值導到一起時，也不會發生重複，就算有“o”老資料也可以區分，而且效率很高，在.NET裡可以直接使用System.Guid.NewGuid()進行生成，在SQL裡也可以使用   NewID()生成。 

優點是：   

同   IDENTITY   列相比，uniqueidentifier   列可以通過   NewID()   函數提前得知新增加的行   ID，為應用程式的後續處理提供了很大友善。   

便于資料庫移植，其它資料庫中并不一定具有   IDENTITY   列，而   Guid   列可以作為字元型列轉換到其它資料庫中，同時将應用程式中産生的   GUID   值存入資料庫，它不會對原有資料帶來影響。   

便于資料庫初始化，如果應用程式要加載一些初始資料，   IDENTITY   列的處理方式就比較麻煩，而   uniqueidentifier   列則無需任何處理，直接用   T-SQL   加載即可。   

便于對某些對象或常量進行永久辨別，如類的   ClassID，對象的執行個體辨別，UDDI   中的聯系人、服務接口、tModel辨別定義等。   

缺點是：   

GUID   值較長，不容易記憶和輸入，而且這個值是随機、無順序的。 

GUID   的值有   16   個位元組，與其它那些諸如   4   位元組的整數相比要相對大一些。這意味着如果在資料庫中使用   uniqueidentifier   鍵，可能會帶來兩方面的消極影響：存儲空間增大；索引時間較慢。   

我也不是推薦GUID最好，其實在不同的情況，我們都可以采用上面的某一種方式，思考了一些利與弊，也友善大家在進行設計時參考。這些也隻是我的一點思考而已，而且可能我知識面限制，會有一些誤論在裡面，希望大家有什麼想法歡迎讨論。

本文轉自 netcorner 部落格園部落格，原文連結： http://www.cnblogs.com/netcorner/archive/2006/12/31/2912451.html ，如需轉載請自行聯系原作者