在我們的數(shù)據(jù)庫設(shè)計(jì)中，不可逃避的就是數(shù)據(jù)庫表的主鍵，可能有很多朋友沒有深入思考過，主鍵的設(shè)計(jì)對整個(gè)數(shù)據(jù)庫的設(shè)計(jì)影響很大，因此我們不得不要重視起來。
主鍵的必要性:
有些朋友可能不提倡數(shù)據(jù)庫表必須要主鍵，但在我的思考中，覺得每個(gè)表都應(yīng)該具有主鍵，不管是單主鍵還是雙主鍵，主鍵的存在就代表著表結(jié)構(gòu)的完整性，表的記錄必須得有唯一區(qū)分的字段，主鍵主要是用于其他表的外鍵關(guān)聯(lián)，本記錄的修改與刪除，當(dāng)我們沒有主鍵時(shí)，這些操作會變的非常麻煩。
主鍵的無意義性：
我強(qiáng)調(diào)主鍵不應(yīng)該具有實(shí)際的意義，這可能對于一些朋友來說不太認(rèn)同，比如訂單表吧，會有“訂單編號”字段，而這個(gè)字段呢在業(yè)務(wù)實(shí)際中本身就是應(yīng)該具有唯一性，具有唯一標(biāo)識記錄的功能，但我是不推薦采用訂單編號字段作為主鍵的，因?yàn)榫哂袑?shí)際意義的字段，具有“意義更改”的可能性，比如訂單編號在剛開始的時(shí)候我們一切順利，后來客戶說“訂單可以作廢，并重新生成訂單，而且訂單號要保持原訂單號一致”，這樣原來的主鍵就面臨危險(xiǎn)了。因此，具有唯一性的實(shí)際字段也代表可以作為主鍵。因此，我推薦是新設(shè)一個(gè)字段專門用為主鍵，此主鍵本身在業(yè)務(wù)邏輯上不體現(xiàn)，不具有實(shí)際意義。而這種主鍵在一定程序增加了復(fù)雜度，所以要視實(shí)際系統(tǒng)的規(guī)模大小而定，對于小項(xiàng)目，以后擴(kuò)展不會很大的話，也查允許用實(shí)際唯一的字段作主鍵的。
主鍵的選擇
我們現(xiàn)在在思考一下，應(yīng)該采用什么來作表的主鍵比較合理，申明一下，主鍵的設(shè)計(jì)沒有一個(gè)定論，各人有各人的方法，哪怕同一個(gè)，在不同的項(xiàng)目中，也會采用不同的主鍵設(shè)計(jì)原則。
第一：編號作主鍵
此方法就是采用實(shí)際業(yè)務(wù)中的唯一字段的“編號”作為主鍵設(shè)計(jì)，這在小型的項(xiàng)目中是推薦這樣做的，因?yàn)檫@可以使項(xiàng)目比較簡單化，但在使用中卻可能帶來一些麻煩，比如要進(jìn)行“編號修改”時(shí)，可能要涉及到很多相關(guān)聯(lián)的其他表，就象黎叔說的“后果很嚴(yán)重”;還有就是上面提到的“業(yè)務(wù)要求允許編號重復(fù)時(shí)”，我們再那么先知，都無法知道業(yè)務(wù)將會修改成什么?
第二：自動編號主鍵
這種方法也是很多朋友在使用的，就是新建一個(gè)ID字段，自動增長，非常方便也滿足主鍵的原則，優(yōu)點(diǎn)是：數(shù)據(jù)庫自動編號，速度快，而且是增量增長，聚集型主鍵按順序存放，對于檢索非常有利;數(shù)字型的，占用空間小，易排序，在程序中傳遞也方便;如果通過非系統(tǒng)增加記錄（比如手動錄入，或是用其他工具直接在表里插入新記錄，或老系統(tǒng)數(shù)據(jù)導(dǎo)入）時(shí)，非常方便，不用擔(dān)心主鍵重復(fù)問題。
缺點(diǎn)：其實(shí)缺點(diǎn)也就是來自其優(yōu)點(diǎn)，就是因?yàn)樽詣釉鲩L，在手動要插入指定ID的記錄時(shí)會顯得麻煩，尤其是當(dāng)系統(tǒng)與其他系統(tǒng)集成時(shí)，需要數(shù)據(jù)導(dǎo)入時(shí)，很難保證原系統(tǒng)的ID不發(fā)生主鍵沖突（前提是老系統(tǒng)也是數(shù)字型的）;如果其他系統(tǒng)主鍵不是數(shù)字型那就麻煩更大了，會導(dǎo)致修改主鍵數(shù)據(jù)類型了，這也會導(dǎo)致其他相關(guān)表的修改，后果同樣很嚴(yán)重;就算其他系統(tǒng)也是數(shù)字型的，在導(dǎo)入時(shí)，為了區(qū)分新老數(shù)據(jù)，可能想在老數(shù)據(jù)主鍵前統(tǒng)一加一個(gè)“o”(old)來表示這是老數(shù)據(jù)，那么自動增長的數(shù)字型又面臨一個(gè)挑戰(zhàn)。
第三：Max加一
由于自動編號存在那些問題，所以有些朋友就采用自己生成，同樣是數(shù)字型的，只是把自動增長去掉了，采用在Insert時(shí)，讀取Max值后加一，這種方法可以避免自動編號的問題，但也存在一個(gè)效率問題，如果記錄非常大的話，那么Max()也會影響效率的;更嚴(yán)重的是并發(fā)性問題，如果同時(shí)有兩人讀到相同的Max后，加一后插入的ID值會重復(fù)，這已經(jīng)是有經(jīng)驗(yàn)教訓(xùn)的了。
第四：自制加一
考慮Max加一的效率后，有人采用自制加一，也就是建一個(gè)特別的表，字段為：表名，當(dāng)前序列值。這樣在往表中插入值時(shí)，先從此表中找到相應(yīng)表的最大值后加一，進(jìn)行插入，有人可能發(fā)現(xiàn)，也可能會存在并發(fā)處理，這個(gè)并發(fā)處理，我們可以采用lock線程的方式來避免，在生成此值的時(shí)，先Lock，取到值以后，再unLock出來，這樣不會有兩人同時(shí)生成了。這比Max加一的速度要快多了。但同樣存在一個(gè)問題：在與其他系統(tǒng)集成時(shí)，脫離了系統(tǒng)中的生成方法后，很麻煩保證自制表中的最大值與導(dǎo)入后的保持一致，而且數(shù)字型都存在上面講到的“o”老數(shù)據(jù)的導(dǎo)入問題。因此在“自制加一”中可以把主鍵設(shè)為字符型的。字符型的自制加一我倒是蠻推薦的，應(yīng)該字符型主鍵可以應(yīng)付很多我們意想不到的情況。
第五：GUID主鍵
目前一個(gè)比較好的主鍵是采用GUID，當(dāng)然我是推薦主鍵還是字符型的，但值由GUID生成，GUID是可以自動生成，也可以程序生成，而且鍵值不可能重復(fù)，可以解決系統(tǒng)集成問題，幾個(gè)系統(tǒng)的GUID值導(dǎo)到一起時(shí)，也不會發(fā)生重復(fù)，就算有“o”老數(shù)據(jù)也可以區(qū)分，而且效率很高，在.NET里可以直接使用System.Guid.NewGuid()進(jìn)行生成，在SQL里也可以使用 NewID()生成。優(yōu)點(diǎn)是：
同 IDENTITY 列相比，uniqueidentifier 列可以通過 NewID() 函數(shù)提前得知新增加的行 ID，為應(yīng)用程序的后續(xù)處理提供了很大方便。
便于數(shù)據(jù)庫移植，其它數(shù)據(jù)庫中并不一定具有 IDENTITY 列，而 Guid 列可以作為字符型列轉(zhuǎn)換到其它數(shù)據(jù)庫中，同時(shí)將應(yīng)用程序中產(chǎn)生的 GUID 值存入數(shù)據(jù)庫，它不會對原有數(shù)據(jù)帶來影響。
便于數(shù)據(jù)庫初始化，如果應(yīng)用程序要加載一些初始數(shù)據(jù)， IDENTITY 列的處理方式就比較麻煩，而 uniqueidentifier 列則無需任何處理，直接用 T-SQL 加載即可。
便于對某些對象或常量進(jìn)行永久標(biāo)識，如類的 ClassID，對象的實(shí)例標(biāo)識，UDDI 中的聯(lián)系人、服務(wù)接口、tModel標(biāo)識定義等。
缺點(diǎn)是：
GUID 值較長，不容易記憶和輸入，而且這個(gè)值是隨機(jī)、無順序的
GUID 的值有 16 個(gè)字節(jié)，與其它那些諸如 4 字節(jié)的整數(shù)相比要相對大一些。這意味著如果在數(shù)據(jù)庫中使用 uniqueidentifier 鍵，可能會帶來兩方面的消極影響：存儲空間增大；索引時(shí)間較慢。
我也不是推薦GUID最好，其實(shí)在不同的情況，我們都可以采用上面的某一種方式，思考了一些利與弊，也方便大家在進(jìn)行設(shè)計(jì)時(shí)參考。這些也只是我的一點(diǎn)思考而已，而且可能我知識面限制，會有一些誤論在里面，希望大家有什么想法歡迎討論。