在与另一个表的PK自动增量链接的表中插入一行

时间:2014-12-05 06:51:34

标签: c# database schema

我有两张桌子

联系表

  • contactID(PK自动增量)
  • 名字
  • 地址

等。

患者表

  • PatientID
  • contactID(FK)

如何首先为患者添加联系信息,然后将该联系人ID链接到患者表 当contactID是自动增量时(因此直到创建行后才知道)

我还有其他表格 - 医生,护士等 也链接到联系表..

教师表

  • TeacherID
  • contactID(FK)

因此,所有联系方式都位于一个表格中。

这是一个很好的数据库设计吗?

或者将每个实体的联系信息放在其自己的表中是否更好..

所以喜欢这个..

患者表

  • PatientID(PK自动增量)
  • 名字
  • 地址

医生表

  • DoctorID(PK自动增量)
  • 名字
  • 地址

在编程方面,只需要一个insert语句就更容易了。 例如。 插入患者值(Id,@ Firstname,@ lastname,@ Address)

但我确实喜欢将联系表分开(因为它规范化了数据),但是在插入之前它不知道contactID是什么问题,也可能需要做两个插入语句(我不是确定怎么做)

=======

回复编辑4

使用登录表,你还有一个userid(int PK)列吗? E.g

登录表 UserId(int PK),用户名,密码..

用户名应该是唯一的

1 个答案:

答案 0 :(得分:0)

您必须首先创建联系人,然后一旦您知道其主键,然后创建患者并参考您现在知道的PK的联系人。或者,如果Patient表中的FK可以为空,您可以首先使用NULL创建患者作为ContactId,创建联系人然后更新患者,但我不会这样做。

外键约束的想法是被引用的行必须存在,因此被引用的行必须存在于引用它的行之前。

如果你真的需要为多个患者提供相同的联系方式,那么我认为这是一个很好的数据库设计。如果这种关系实际上是一对一的,那么你就不需要将它们分成两个表。根据您的示例,您可能需要的是一个Person表,您可以在其中放置医生,教师和患者的所有常见属性。

修改 我认为你继承了你真正追求的东西。在关系数据库中实现继承的风格很少,但这只是一个例子。

Person database design

Nurse和Doctor中的PersonId是引用Person表的外键,但它们也是这些表的主键。

要插入Nurse-row,您可以这样做(SQL Server):

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

<强> EDIT2: Google透露,SCOPE_IDENTITY() [mysql doc]

LAST_INSERT_ID()等效于mysql

<强> EDIT3: 我不会将医生和护士分成他们自己的表,以便列重复。进行没有内连接的选择可能会更有效,但性能不应该是唯一的标准,特别是如果性能差异不明显。在很多情况下,您只需要普通人数据,这样您就不必总是进行连接。将每个人放在同一个表中可以在一个表中查找一个人。在单个表中具有共同属性还允许您必须让医生也是患者而不重复任何数据。之后,如果您想拥有更多常用属性,则需要将它们添加到每个&t 34;派生的&#34;我也向你保证,有一天你或其他人忘记在其中一个表格中添加属性。

如果由于某种原因你仍然担心性能而且愿意牺牲规范化以获得性能,另一种可能性是将所有人员列放在同一个表中并且可能在那里有一个类型列来区分它们并且只是有很多null列,以便所有护士列对医生来说都是null等等。即使您没有使用实体框架,也可以阅读inheritance implementation strategies以了解相关信息。

<强> EDIT4: 即使您目前没有任何专门针对护士的专栏,如果将来可能会略有可能,我仍会为他们创建一个表格。进行内部联接是找到护士的一种非常好的方法,或者你可以在WHERE子句中做到这一点(可能有十亿种方法可以做到这一点)。您可以在Person表中使用type列,但这会阻止同一个人同时成为医生和患者。另外在我看来,单独的表格更严格&#34;严格&#34; (未来)开发人员更清楚。

我可能会在User表中使PersonId可以为空,因为您可能拥有组织中不是真实用户的用户。例如管理员或类似的服务用户。考虑现实世界的实体(忘记外键和无效),每个用户绝对是组织的一部分吗?但这一切都取决于您和软件的要求。数据库设计应该从实体关系设计开始,在这种设计中,您可以在不考虑如何将它们映射到关系数据库的情况下找出真实世界的关系。这有助于您弄清楚实际需求是什么。