-1

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

  • 医生
  • 护士

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

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

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

4

3 回答 3

1

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

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

于 2013-04-18T12:46:22.843 回答
0

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

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

一个派对可以扮演许多角色。一个这样的角色是护士。也许护士回到学校并成为一名医生。

如果您阅读一些数据建模书籍（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)
于 2013-04-18T18:34:47.490 回答
0

有3种可能的方法来解决这个问题：

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

把它放在 2 个特定的表中。Doctor 和 Nurse 都有他们自己需要的所有列。在某种程度上，这是非常可行的，您可以决定选择哪一个。但是，使用奇数和偶数 id 是没有意义的（您认为：Select * from tab_doctor, tab_nurse where id = even?）。如果您确实使用这样的 id 并且有人将偶数 id 添加到不均匀表中，您会遇到问题，为防止这种情况，您必须编写触发器来检查 id（会降低性能）。

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

每个实现都有很多优点和缺点，这取决于很多因素（不仅是我提到的那些，还考虑表格的大小等）。

于 2013-04-18T12:42:27.200 回答