Inheritance 建模一个非常简单的isA关系：2个带有偶数/奇数ID的表还是3个表？

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

医生 护士 这永远不会改变，也就是说，没有其他类型的员工。两种实体类型之间有很大的重叠，例如登录信息相同，但也有很大的差异。到目前为止，我们可以做到：

一张医生表只有偶数ID 2、4、6等，一张护士表只有奇数ID 1、3、5等 3个表，一个用于捕获普通父实体员工，一个用于每个子实体医生和护士

---

我无法说服我的一位同事，在我们的项目中，第一个设计更好，主要是因为它简单，特别是普通操作的连接更少，性能更好。为什么第一种设计更好？

有三种可能的解决方法：

把所有的东西放在一张桌子上。这是迄今为止最容易使用的select*from personel，其中type='doctor'。这样做的最大缺点是，属于某个类型的所有列都不用于相反的类型，反之亦然

把它放在两个特定的表格中。医生和护士都有自己需要的专栏。在某种程度上，这是非常可行的，因为您可以决定从中选择哪一个。然而，在您思考的地方使用奇数和偶数id毫无意义：从tab\u医生、tab\u护士中选择*其中id=不均匀？。如果您确实像这样使用id，并且有人将偶数id添加到不均匀表中，您将遇到问题，为了防止出现这种情况，您必须编写触发器来检查id是否会导致性能下降

最后一种可能是使用3个表作为子实体，如您所说。然而，这一个在表之间使用了大量的通信。正如你所说的，它的简单性不在其他两个选项的级别上

---

每个实现都有好的方面和坏的方面，这取决于很多因素，不仅仅是我提到的那些因素，想想表的大小等等。

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

---

编辑：既然你用ORM标记了这个问题，我想ORM将完成所有的连接工作。第一个解决方案不可能被ORM轻易地否定，而第二个解决方案则是ORM可以在没有任何定制的情况下解决的。

你应该使用团队和角色模型

一方代表一个组织、个人，或者可能是一个自动代理

一个政党可以扮演许多角色。其中一个角色是护士。也许护士回到学校，成为一名医生

如果您阅读了一些数据建模书籍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)