快捷導(dǎo)航

sqlserver主鍵設(shè)計(jì)的注意點(diǎn)

更新時(shí)間：2012年07月27日 09:27:02 作者：

在數(shù)據(jù)庫設(shè)計(jì)中，主鍵用于惟一地標(biāo)識(shí)表中的某一條記錄

在設(shè)計(jì)主鍵的時(shí)候往往需要考慮以下幾點(diǎn)：

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

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

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

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

復(fù)制代碼代碼如下:

 
--主表 
CREATE TABLE PP_MPSHeader( 
　　BillNo VARCHAR(20) NOT NULL PRIMARY KEY, 
　　PlanDate DATETIME NOT NULL 
) 
--從表 
CREATE TABLE PP_MPSBody( 
　　BillNo VARCHAR(20) NOT NULL, 
　　LineNumber SMALLINT NOT NULL, 
　　ProductID INT NOT NULL, 
　　ProductQty DECIMAL(18,2) NOT NULL, 
PRIMARY KEY(BillNo,LineNumber) 
) 
--設(shè)置外鍵 
ALTER TABLE PP_MPSBody 
ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillNo) REFERENCES PP_MPSHeader(BillNo) 

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

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

復(fù)制代碼代碼如下:

 
--主表 
CREATE TABLE PP_MPSHeader( 
　　BillId INT PRIMARY KEY, 
　　BillNo VARCHAR(20) NOT NULL, 
　　PlanDate DATETIME NOT NULL 
) 
--從表 
CREATE TABLE PP_MPSBody( 
　　BillId INT PRIMARY KEY, 
　　LineNumber SMALLINT NOT NULL, 
　　ProductID INT NOT NULL, 
　　ProductQty DECIMAL(18,2) NOT NULL, 
PRIMARY KEY(BillId,LineNumber) 
) 
--設(shè)置外鍵 
ALTER TABLE PP_MPSBody 
ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillId) REFERENCES PP_MPSHeader(BillId) 

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

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

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

您可能感興趣的文章: