建模一个非常简单的isA关系：2个表有偶数/奇数ids或3个表？

Question

我们项目中有两种类型的医院员工

• 医生
• 护士

这永远不会改变（即没有其他员工类型）。两种实体类型之间存在相当重叠（例如登录信息相同），但也存在很大差异。到目前为止，我们可以：

• 一个doctors表，只有id s（2,4,6等）和nurses表，只有奇数id s（1,3,5）等）
• 3个表，一个用于捕获公共父实体（staffs），另一个表用于每个子实体（doctors和nurses）

我不能说服我的一位同事，我们项目中的第一个设计更好，主要是因为它的简单性（特别是少于常用操作的连接）和更好的性能。为什么第一个设计更好？

Answer 1

第一种设计并不是更好，因为它是一种自定义解决方案，而第二种设计遵循关系数据库原则。

编辑：既然你用ORM标记了问题，我想ORM会做所有的加入工作。 ORM无法轻易找到第一个解决方案，而第二个解决方案是ORM可以在没有任何自定义的情况下解决的问题。

Answer 2

有三种方法可以解决这个问题：

将所有内容放入1个表格中。到目前为止，这是最容易使用的（选择*来自personel，其中type ='doctor'）。这方面的一个重大缺点是属于某种类型的所有列都没有用于相反的类型（反之亦然）。

将它放在2个特定的表中。医生和护士都有自己需要的所有栏目。在某种程度上，这是非常可行的，你可以决定选择哪一个。但是，使用奇数和偶数id是没有意义的（你在哪里思考：从tab_doctor中选择*，tab_nurse，其中id =不均匀？）。如果你确实使用了这样的id，并且有人在不平衡的表中添加偶数id就会出现问题，为了防止这种情况，你必须编写一个触发器来检查id（使性能更差）。

最后一种可能性是使用3个表，就像你说的那样使用子实体。然而，这个使用表之间的大量通信。而且它很简单，因为你所声明的不是其他两个选项的水平。

每个实施都有好处和缺点，取决于很多因素（不仅是我提到的因素，还要考虑表的大小等）。

Answer 3

您应该使用派对和角色模型。

缔约方代表组织，个人或自动代理。

派对可以扮演很多角色。其中一个角色是护士。也许护士会回到学校并成为医生。

如果您阅读了一些数据建模书籍（Hay，Silverston，Fowler），这是标准方法。如果你没有理由不使用标准方法，那就很好。

PARTY
long id

INDIVIDUAL : PARTY
String name

ROLE
Party party
Date from_date
Date to_date

DOCTOR_ROLE : ROLE

NURSE_ROLE : ROLE

如果您使用的是单表继承，那么您的表将如下所示：

PARTY
id 
type FK PARTY_TYPE
name
PK id

ROLE
party_id
type FK ROLE_TYPE
from_date
to_date null
PK (party_id, type, from_date)