将关联表用于一对多关系是否常见？

Question

我目前与一些工作中的数据库架构师在概念上存在分歧。我在这个领域的教育完全来自 UofGoogle，所以我确信他们是对的，但无法在网上找到支持他们的证据。

我们正在讨论的数据库部分与不同领域内的制造设备有关。有一个包含所有唯一 AREA_CD 的表。每个区域可以包含多件装备（EQUIP_CD），但单件装备不能在多个区域。即这是一个（AREA_CD）对多（EQUIP_CD）的关系。

我对db设计的理解是，我们应该有一个与区域表直接相关的设备的表，其中：AREA_CD= PK & FK to area table EQUIP_CD= PK（组合PK是因为有一些设备共享相同的代号，但不一样。这是我们试图升级的遗留系统的不幸现实）。

架构师说最好的做法是通过关联表连接面积表和设备表，我认为这是专门用于多对多关系的。

如果 EQUIP_CD 指的是特定类型的设备（具有我们感兴趣的属性），其中多个设备可能存在于不同的区域，那么这对我来说是有意义的。然而，这将是一个多对多的关系，这里不是这种情况。我们有一些共享代号，指的是不同类型的设备，属性取决于它们所在的区域。

他们使用关联表的理由如下：

1. 数据保护。关联表受代码表保护.. 但我认为在这种情况下这不会增加任何价值。还有其他表连接到 EQUIP_CD 将保护它。
2. 未来的灵活性。这对我来说是可以理解的。
3. 最佳实践。是吗？

所以我的问题..是将关联表用于一对多关系的最佳实践吗？除了上述三个之外，这种设计还有其他理由吗？

我不是想挑战我的同事，只是想进一步学习。先感谢您！

更新：数据模型正在修复中，我们正在摆脱那些关联表。

Answer 1

对于简单的情况，您是对的，不需要为一对多关系设置单独的链接表。

在我的脑海中，我只能想到几个示例，其中可能需要为关系创建单独的表：

• 如果您正在跟踪行的历史记录（在您的业务逻辑层中，通过触发器或“临时表”，如果 Oracle 支持它们）并且存在您不想在设备表中跟踪更改的关系属性本身。可能是您描述的那些代码，或者可能是当前负责在该位置维护设备的人员。

• 如果您设想以后需要支持多<->多关系。
  尽管在这种情况下这似乎不太可能。

• 如果您必须在需要所有关系的链接表的遗留框架中支持某些奇怪的东西（这是合理的，因为您已经描述了需要解决其他遗留的奇怪问题）。

• 以这种方式工作是一种简单的本地做法（显然这并不是一个好主意，但它可能会使您无权与之抗争！）