在設計主鍵的時候往往需要考慮以下幾點：
1.無意義性：此處無意義是從用戶的角度來定義的。這種無意義在一定程度上也會減少數(shù)據(jù)庫的信息冗余。常常有人稱呼主鍵為內部標識，為什么會這樣稱呼，原因之一在于“內部”，所謂內部從某種程度上來說就是指表記錄，從大的范圍來說就是數(shù)據(jù)庫，如果你在設計的時候選擇了對用戶來說有意義的信息來作為主鍵，那么遲早會面對用戶提出對這塊信息進行更新的需求，那么你就違背了它應有的靜態(tài)。
2.靜態(tài)性：主鍵除了唯一地標識一條記錄及外鍵的關聯(lián)外，應不再考慮其他的意義，最理想的狀態(tài)就是在產(chǎn)生后不再變動，所以在主鍵值產(chǎn)生后應考慮不對他進行更新等操作。如果進行了更新操作那么至少說明這塊信息對于用戶來說是有一定的意義，那么你就違背了應有的無意義性。（對數(shù)據(jù)進行整合等操作時可能需要對主鍵進行處理，這樣做是為了保證數(shù)據(jù)庫的完整性——記錄的唯一，不在此考慮范圍之內。）
無意義性往往可以決定其靜態(tài)性。
3.簡短性：既包含主鍵組成字段數(shù)量要少，還包含主鍵中單個字段存儲類型簡短，一般采用整形；對于前者主要考慮的是外鍵關聯(lián)的因素；對于后者主要考慮的是性能。主鍵的簡短對表的關聯(lián)便捷性及檢索的性能有極大的幫助。
看看下面具有缺陷的“主生產(chǎn)計劃表”主鍵設計方案(MsSQL)：
復制代碼 代碼如下:
--主表
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)
)
--設置外鍵
ALTER TABLE PP_MPSBody
ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillNo) REFERENCES PP_MPSHeader(BillNo)
這是典型的主從表結構。主表記錄什么時候下達哪個單號的主計劃，從表記錄的是此計劃生產(chǎn)哪些產(chǎn)品各多少數(shù)量，通過BillNo進行關聯(lián)。當用戶在下達一份主生產(chǎn)計劃后，很可能會發(fā)現(xiàn)由于粗心大意輸錯了BillNo中計劃單號信息，那么在他修改單號時，代碼編寫者需要在代碼中控制從表的單號跟隨主表的單號進行變動，否則單據(jù)將在外鍵的約束下無法保存，如果沒有外鍵的約束，那么數(shù)據(jù)將失去其完整性。
如果按照上面的3個注意點，解決方案如下(MsSQL)：
復制代碼 代碼如下:
--主表
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)
)
--設置外鍵
ALTER TABLE PP_MPSBody
ADD CONSTRAINT FK_PP_MPSHeader_MPSBody FOREIGN KEY(BillId) REFERENCES PP_MPSHeader(BillId)
現(xiàn)在，主從表通過BillId進行關聯(lián)，當產(chǎn)生一份生產(chǎn)計劃時，生成一個BillId，對于用戶來說根本沒有意義，在隨后單據(jù)信息的改動中也不會出現(xiàn)上面的主從信息協(xié)調問題。同時從表的信息量小于上面的缺陷設計。因為原外鍵BillNo的長度從20個字節(jié)變成了現(xiàn)在的BillId4個字節(jié)，減少了信息的冗余。
這樣的例子其實很多，比如：
有的設計原材料表時，使用零部件圖號作為主鍵，那就意味著采購、生產(chǎn)、銷售等等相關表中都會出現(xiàn)零部件圖號的外鍵信息，當零部件圖號信息發(fā)生變動時，這些所有先關的信息都需要跟著變動，這種缺陷如果不從根本上解決，那么你可能需要寫個零部件圖號變動處理過程，來批量處理這些問題，在處理的過程中可能你還得考慮處理的順序問題……；
有的設計，使用身份證件號作為人員表的主鍵，但是身份證后來從15位變成了18位，這就意味著人員表中每個人的人員身份證信息都需要變動，如果你是某個社保機構此應用程序的設計人員，那么你就需要更新上百萬條記錄；那些所有由人員表通過身份證件號外聯(lián)出去的信息記錄將會以億計數(shù)，那么也許余生你就不需要做其他工作了。
所以選擇無意義的鍵值來作為主鍵的一部分，也是從長遠意義上來避免類似這種改動的發(fā)生。
您可能感興趣的文章:- SQLServer主鍵和唯一約束的區(qū)別
- 如何獲取SqlServer2005表結構(字段,主鍵,外鍵,遞增,描述)
- 深入Mysql,SqlServer,Oracle主鍵自動增長的設置詳解
- SQLSERVER聚集索引和主鍵(Primary Key)的誤區(qū)認識
- sqlserver數(shù)據(jù)庫主鍵的生成方式小結(sqlserver,mysql)
- 小議sqlserver數(shù)據(jù)庫主鍵選取策略
- sqlserver主鍵自增的實現(xiàn)示例
