首頁 培訓計劃 培訓課程 企業內訓 學員論壇 技術文章 成功案例 師資簡介 關于我們 在線留言  
數據庫資料
數據庫關于主鍵的問題

文章來源:www.cnblogs.com 作者: 發布日期:2009-11-05
打 印】【關 閉

在我們的數據庫設計中,不可逃避的就是數據庫表的主鍵,可能有很多朋友沒有深入思考過,主鍵的設計對整個數據庫的設計影響很大,因此我們不得不要重視起來。

主鍵的必要性:

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

主鍵的無意義性

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

主鍵的選擇

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

第一:編號作主鍵

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

第二:自動編號主鍵

      這種方法也是很多朋友在使用的,就是新建一個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最好,其實在不同的情況,我們都可以采用上面的某一種方式,思考了一些利與弊,也方便大家在進行設計時參考。這些也只是我的一點思考而已,而且可能我知識面限制,會有一些誤論在里面,希望大家有什么想法歡迎討論。

打 印】【關 閉

上一篇:Server Application Error(http 500 錯誤,IIS不能解析
下一篇:sql2005數據同步
相關新聞
版權所有©威課網 粵ICP備13058727號