程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> MSSQL >> sqlserver主鍵設計的留意點

sqlserver主鍵設計的留意點

編輯:MSSQL

sqlserver主鍵設計的留意點。本站提示廣大學習愛好者:(sqlserver主鍵設計的留意點)文章只能為提供參考,不一定能成為您想要的結果。以下是sqlserver主鍵設計的留意點正文


在設計主鍵的時刻常常須要斟酌以下幾點:

1.有意義性:此處有意義是從用戶的角度來界說的。這類有意義在必定水平上也會削減數據庫的信息冗余。經常有人稱謂主鍵為外部標識,為何會如許稱謂,緣由之一在於“外部”,所謂外部從某種水平下去說就是指表記載,從年夜的規模來講就是數據庫,假如你在設計的時刻選擇了對用戶來講成心義的信息來作為主鍵,那末早晚會見對用戶提出對這塊信息停止更新的需求,那末你就違反了它應有的靜態。

2.靜態性:主鍵除獨一地標識一筆記錄及外鍵的聯系關系外,應不再斟酌其他的意義,最幻想的狀況就是在發生後不再更改,所以在主鍵值發生後應斟酌纰謬他停止更新等操作。假如停止了更新操作那末至多解釋這塊信息關於用戶來講是有必定的意義,那末你就違反了應有的有意義性。(對數據停止整合等操作時能夠須要對主鍵停止處置,如許做是為了包管數據庫的完全性——記載的獨一,不在此斟酌規模以內。)
有意義性常常可以決議其靜態性。

3.冗長性:既包括主鍵構成字段數目要少,還包括主鍵中單個字段存儲類型冗長,普通采取整形;關於前者重要斟酌的是外鍵聯系關系的身分;關於後者重要斟酌的是機能。主鍵的冗長對表的聯系關系便捷性及檢索的機能有極年夜的贊助。

看看上面具出缺陷的“主臨盆籌劃表”主鍵設計計劃(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)

這是典范的主從表構造。主表記載甚麼時刻下達哪一個單號的主籌劃,從表記載的是此籌劃臨盆哪些產物各若干數目,經由過程BillNo停止聯系關系。當用戶鄙人達一份主臨盆籌劃後,極可能會發明因為粗枝大葉輸錯了BillNo上鉤劃單號信息,那末在他修正單號時,代碼編寫者須要在代碼中掌握從表的單號追隨主表的單號停止更改,不然單據將在外鍵的束縛下沒法保留,假如沒有外鍵的束縛,那末數據將掉去其完全性。

假如依照下面的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)

如今,主從表經由過程BillId停止聯系關系,當發生一份臨盆籌劃時,生成一個BillId,關於用戶來講基本沒成心義,在隨後單據信息的修改中也不會湧現下面的主從信息調和成績。同時從表的信息量小於下面的缺點設計。由於原外鍵BillNo的長度從20個字節釀成了如今的BillId4個字節,削減了信息的冗余。

如許的例子其實許多,好比:
有的設計原資料表時,應用零部件圖號作為主鍵,那就意味著推銷、臨盆、發賣等等相干表中都邑湧現零部件圖號的外鍵信息,當零部件圖號信息產生更改時,這些一切先關的信息都須要隨著更改,這類缺點假如不從基本上處理,那末你能夠須要寫個零部件圖號更改處置進程,來批量處置這些成績,在處置的進程中能夠你還得斟酌處置的次序成績……;
有的設計,應用身份證件號作為人員表的主鍵,然則身份證後來從15位釀成了18位,這就意味著人員表中每一個人的人員身份證信息都須要更改,假如你是某個社保機構此運用法式的設計人員,那末你就須要更新上百萬筆記錄;那些一切由人員表經由過程身份證件號外聯出去的信息記載將會以億計數,那末或許余生你就不須要做其他任務了。

所以選擇有意義的鍵值來作為主鍵的一部門,也是從久遠意義下去防止相似這類修改的產生。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved