在設(shè)計主鍵的時候往往需要考慮以下幾點：

1.無意義性：此處無意義是從用戶的角度來定義的。這種無意義在一定程度上也會減少數(shù)據(jù)庫的信息冗余。常常有人稱呼主鍵為內(nèi)部標識，為什么會這樣稱呼，原因之一在于“內(nèi)部”，所謂內(nèi)部從某種程度上來說就是指表記錄，從大的范圍來說就是數(shù)據(jù)庫，如果你在設(shè)計的時候選擇了對用戶來說有意義的信息來作為主鍵，那么遲早會面對用戶提出對這塊信息進行更新的需求，那么你就違背了它應(yīng)有的靜態(tài)。

2.靜態(tài)性：主鍵除了唯一地標識一條記錄及外鍵的關(guān)聯(lián)外，應(yīng)不再考慮其他的意義，最理想的狀態(tài)就是在產(chǎn)生后不再變動，所以在主鍵值產(chǎn)生后應(yīng)考慮不對他進行更新等操作。如果進行了更新操作那么至少說明這塊信息對于用戶來說是有一定的意義，那么你就違背了應(yīng)有的無意義性。（對數(shù)據(jù)進行整合等操作時可能需要對主鍵進行處理，這樣做是為了保證數(shù)據(jù)庫的完整性——記錄的唯一，不在此考慮范圍之內(nèi)。）
無意義性往往可以決定其靜態(tài)性。

3.簡短性：既包含主鍵組成字段數(shù)量要少，還包含主鍵中單個字段存儲類型簡短，一般采用整形；對于前者主要考慮的是外鍵關(guān)聯(lián)的因素；對于后者主要考慮的是性能。主鍵的簡短對表的關(guān)聯(lián)便捷性及檢索的性能有極大的幫助。

看看下面具有缺陷的“主生產(chǎn)計劃表”主鍵設(shè)計方案(MsSQL)：

這是典型的主從表結(jié)構(gòu)。主表記錄什么時候下達哪個單號的主計劃，從表記錄的是此計劃生產(chǎn)哪些產(chǎn)品各多少數(shù)量，通過BillNo進行關(guān)聯(lián)。當用戶在下達一份主生產(chǎn)計劃后，很可能會發(fā)現(xiàn)由于粗心大意輸錯了BillNo中計劃單號信息，那么在他修改單號時，代碼編寫者需要在代碼中控制從表的單號跟隨主表的單號進行變動，否則單據(jù)將在外鍵的約束下無法保存，如果沒有外鍵的約束，那么數(shù)據(jù)將失去其完整性。

如果按照上面的3個注意點，解決方案如下(MsSQL)：

現(xiàn)在，主從表通過BillId進行關(guān)聯(lián)，當產(chǎn)生一份生產(chǎn)計劃時，生成一個BillId，對于用戶來說根本沒有意義，在隨后單據(jù)信息的改動中也不會出現(xiàn)上面的主從信息協(xié)調(diào)問題。同時從表的信息量小于上面的缺陷設(shè)計。因為原外鍵BillNo的長度從20個字節(jié)變成了現(xiàn)在的BillId4個字節(jié)，減少了信息的冗余。

這樣的例子其實很多，比如：
有的設(shè)計原材料表時，使用零部件圖號作為主鍵，那就意味著采購、生產(chǎn)、銷售等等相關(guān)表中都會出現(xiàn)零部件圖號的外鍵信息，當零部件圖號信息發(fā)生變動時，這些所有先關(guān)的信息都需要跟著變動，這種缺陷如果不從根本上解決，那么你可能需要寫個零部件圖號變動處理過程，來批量處理這些問題，在處理的過程中可能你還得考慮處理的順序問題……；
有的設(shè)計，使用身份證件號作為人員表的主鍵，但是身份證后來從15位變成了18位，這就意味著人員表中每個人的人員身份證信息都需要變動，如果你是某個社保機構(gòu)此應(yīng)用程序的設(shè)計人員，那么你就需要更新上百萬條記錄；那些所有由人員表通過身份證件號外聯(lián)出去的信息記錄將會以億計數(shù)，那么也許余生你就不需要做其他工作了。

所以選擇無意義的鍵值來作為主鍵的一部分，也是從長遠意義上來避免類似這種改動的發(fā)生。

最新評論