組中與另一臺

Question

我有兩個表

接觸表

• 的ContactID（PK自動遞增）
• 姓
• 名字
• 的PK自動增量鏈接表中插入一行地址

等

病人表

• PatientID
• 的ContactID（FK）

我怎麼能先添加聯繫人信息的病人，然後鏈接的ContactID患者表 時的ContactID是自動增量（因此不知道創建一行之後直至）

我也有其它表 -Doctor，NU RSE等 也鏈接到聯繫表..

教師表

• TeacherID
• 的ContactID（FK）

因此，因此所有的聯繫方式都位於一個表。

這是一個良好的數據庫設計？

或者是更好地把聯繫人信息在它自己的表中的每個實體..

所以這樣的..

病人表

• PatientID（PK自動遞增）
• 姓名
• 姓氏
• 地址

醫生表

• DoctorID（PK自動遞增）
• 姓
• 名字
• 地址

在編程方面，它是容易只是有一個刀片聲明。 例如。 INSERT INTO病人的價值觀（ID，@名字，姓氏@，@address）

但我喜歡分離（因爲其標準化數據）的接觸表，但隨後它與不知道的ContactID是什麼，直到後問題它被插入，並且還可能需要做兩個INSERT語句（這我不知道該怎麼做）

=======

回覆EDIT 4

隨着登錄表，你會仍然有一個用戶ID（INT PK）列？ 如

登錄表 用戶ID（INT PK），用戶名，密碼..

用戶名應該是唯一的

Answer 1

您必須先創建聯繫人，然後，一旦你知道它的主鍵，然後創建患者並參考你現在知道的PK的聯繫方式。或者，如果Patient表中的FK爲空，則可以先創建患者爲NULL，然後創建聯繫人，然後更新患者，但我不會這樣做。

外鍵約束的想法是被引用的行必須存在，因此被引用的行必須存在於引用它的行之前。

如果你真的需要能夠爲多個患者擁有相同的聯繫人，那麼我認爲這是很好的db設計。如果這種關係實際上是一對一的，那麼你就不需要將它們分成兩個表格。給出你的例子，可能是你需要的是一個Person表格，你可以把所有的醫生，老師和患者的共同屬性。

編輯： 我認爲這是繼承你真的以後。在關係數據庫中實現繼承的方式很少，但這裏有一個例子。

Person database design

PERSONID在護士和醫生外鍵引用Person表，但他們也是這些表的主鍵。

要插入護士行，你可以做這樣的（SQL服務器）：

INSERT INTO Person(FirstName) VALUES('Test nurse') 
GO 
INSERT INTO Nurse(PersonId, IsRegistered) VALUES(SCOPE_IDENTITY(), 1) 
GO 

EDIT2： 谷歌顯示，SCOPE_IDENTITY()相當於在MySQL中是LAST_INSERT_ID()[mysql doc]

EDIT3： 我不會將醫生和護士分別放入自己的表格中，以使列被複制。做一個沒有內連接的選擇可能會更有效，但性能不應該是唯一的標準，特別是如果性能差異不明顯。在很多情況下，當你只需要普通人數據時，無論如何你並不總是必須進行連接。將每個人放在同一張桌子裏，可以在一張桌子上尋找一個人。在一個表格中擁有共同的屬性也允許您必須擁有也是患者的醫生，而不需要複製任何數據。後來，如果你想擁有更多的常用屬性，你需要將它們添加到每個「派生」表中，我會向你保證，有一天你或別人忘記在其中一個表中添加屬性。

如果由於某種原因，您仍然擔心性能，並且願意犧牲規範化以獲得性能，另一種可能性是將所有人員列放在同一個表中，並且可能有一個類型列以區分它們，並且只有一個很多空列，以便所有護士列對於醫生等都是空的。您可以閱讀inheritance implementation strategies以瞭解即使您未使用實體框架的想法。

EDIT4： 即使你沒有在目前的任何特定的護柱，我仍然會創建一個表，他們是否會有在未來甚至可能略。做一個內部連接是找到護士的一個很好的方法，或者你可以在WHERE子句中做到這一點（可能有十億種方法來做到這一點）。您可以在人員表格中輸入欄位，但會阻止同一人同時成爲醫生和患者。同樣在我看來，單獨的表格對於（未來）開發者來說更​​「嚴格」和更清晰。

我可能會在用戶表中創建PersonId爲空，因爲您可能有不是組織中實際人員的用戶。例如管理員或類似的服務用戶。按照現實世界的實體來考慮（忘記外鍵和空字符），每個用戶都是組織的絕對組成部分嗎？但所有這些都取決於你和軟件的要求。數據庫設計應該從一個實體關係設計開始，在這個設計中你可以找出現實世界的關係，而不必考慮它們將如何映射到關係數據庫。這有助於您弄清楚實際要求是什麼。