2016-12-30 68 views
0

我是SQL Server的新手,如果能幫助我,我會非常感激。我可以將此列設置爲主鍵嗎?

因此,醫療服務提供者和內部我們爲每位患者分配一個ID(例如,1234)。我目前正在構建另一個數據庫,我只是想知道我可以使用我們的內部ID作爲主鍵,因爲它們是唯一的?如果是這樣,因爲我不打算對主鍵進行任何計算,我可以將它們設置爲主鍵的字符串/字符數據類型嗎?

+0

如果'ID'總是數字,那麼使用'Integer'類型。整數類型並不意味着你必須對它們進行一些計算。在查詢或排序結果時,整數可能比'Varchar' –

+0

'INT'數據類型定義爲更常見且更快速的數據類型。 –

+0

當有些事情可能意味着某件事情不僅僅是關鍵時,要小心使用某些事物作爲主鍵。如果由於「內部ID」發生改變或由於某些其他原因需要更改密鑰,則密鑰取決於外部因素,最好將其定義爲正常字段,並使用數據庫生成的密鑰。 – trincot

回答

1

主鍵的條件是該鍵在表中是唯一的並且從不NULL

您的患者ID似乎具有這些特徵。

也就是說,開發合成主鍵(自動遞增/身份/序列取決於數據庫)有很好的理由。更重要的是,實際的患者ID可能是敏感信息。例如,患者可能在登錄時使用該ID,或者可能在發票上打印。

在整個數據庫中重複使用敏感信息可能不是一個好主意。出於這個原因,將使用「內部」id來指代表格中的患者,並且所有敏感信息將被包含在一個或幾個表格中。

如果「患者身份證」是政府身份證(「社會安全號碼」)或電子郵件地址,這可能會更明顯。

2

總之,是的,你可以但它是不推薦!

給你一些擡起頭:

  • 主鍵不應該改變
  • 不能使用自然鍵或按鍵形式的其它系統
  • 他們不能有任何公式
  • 使用短但合適的鑰匙類型

如果您有一個外部鑰匙,你想用它來找一些患者,爲它創建另一列並添加UNIQUE Constraint。 只是不要忘了添加索引該列

閱讀此篇我的更多信息:

http://pilpag.blogspot.dk/2016/06/relational-database-designsimple-rules.html

1

是的,但ID也可以是數值和主鍵 - 它不不必是一個字符串。只要ID是唯一的,你應該沒問題。

0

是的,如果它們是唯一的,你可以使用你的內部ID;對於char/varchar數據類型,PK限制爲900字節。所以如果你的ID是int就沒問題。但是,如果你的身份證可以隨時間改變,或者可以重複使用,那麼我強烈建議不要使用它們來避免混亂。我更喜歡使用代理鍵,如身份

0

如果我理解正確,您將爲每個患者分配一個數字以便唯一標識它們。因此,一份報告將包含患者編號,而不僅僅是可能含糊不清的患者姓名。您不會更改患者編號,因爲那樣您必須在所有數據庫中更改此編號,並且必須重新打印仍然需要患者的所有文檔。這使得這個號碼成爲任何數據庫中病人表的完美主鍵。

可能將生成的技術ID用作表的主鍵,並且僅將患者編號作爲表中的另一個字段(當然仍然具有唯一約束,因爲它仍然是唯一的業務關鍵字識別患者)。是否做這件事主要是個人喜好和經驗。我比ID更喜歡自然鍵(因此會使患者編號成爲主鍵)。這起源於與具有數千個表和多個層次結構的相當大的數據庫一起工作,其中自然鍵被證明導致更快的查詢,增強的數據一致性和更容易的維護。不過,其他人可能有不同的經歷。

所以,在我看來,病人號碼似乎是完美的自然主鍵。

相關問題