数据库优化/规范化 - 外键出现在“太多”表中答案

【问题标题】：Database optimization/normalization - foreign key appearing in "too many" tables数据库优化/规范化 - 外键出现在“太多”表中
【发布时间】：2012-01-30 07:00:21
【问题描述】：

我做了很多研究，我相信我的数据库在 4th NF 中（被告知没有必要再进一步），但仍然感觉有些不对。

我有一个表 TRUNK，两个表通过外键引用： RATECARD 作为一个主干可用于许多费率卡（区别在于有效时间、呼叫计划等）；此外，我还有一个 RATEBUYINGINFO，它基本上是您从中继提供商处下载的信息，其中包含有关不同目的地和类似目的地的费率信息。显然，随着价格随时间变化，更多的 RATEBUYINGINFO 对象可以与一个主干相关联，但是 RATEBUYINGINFO 和 RATECARD 没有直接连接，除了它们可能引用一个主干，所以我在这两个表中都有 TrunkID 作为外键。

然后我有基于某些 RATECARD 的销售率信息（RATESELLINGINFO 表）以及目的地信息以及中继信息，所有这些信息都在 RATEBUYINGINFO 表中进行跟踪（不，我没有看到指出将 DESTINATION 作为单独的表单独列出，因为不同提供商的不同中继不提供唯一的目的地名称），所以我在 RATESELLINGINFO 表中有外键 RateCardID 和 RateBuyingInfoID 作为外键。

现在的问题是，通过这两个外键，最后一个表可以访问两个 TrunkID 值（一个在 RATECARD 中，一个在 RATEBUYINGINFO 中），它们应该始终相同（显然，一个销售率是指一个主干）但是数据库架构不会以任何方式保证这一点。这个问题有没有优雅的解决方案？

【问题讨论】：

标签： mysql database-design optimization normalization telephony

【解决方案1】：

当您提出此类问题时，请始终包含 SQL CREATE TABLE 语句和一些示例数据作为 SQL INSERT 语句。 SQL 比您的 cmets 更可靠且不那么模棱两可。（您现在可以编辑您的问题并添加这些内容，以便从稍后阅读此内容的人那里获得更好的答案。）

RATECARD 和 RATEBUYINGINFO 表中的中继 ID 应该可能是这两个表中主键的一部分或唯一约束的一部分。如果是，那么您可以在 RATESELLINGINFO 中使用重叠的外键约束将中继 ID 存储一次。类似的东西

...
foreign key (trunk_id, rate_card_id) 
  references ratecard (trunk_id, rate_card_id),
foreign key (trunk_id, rate_buying_info_id)
  references rate_buying_info (trunk_id, rate_buying_info_id)
...

如果您完成了一个完整的关系模型，则无论如何（可能）Trunk id 都会出现在 RATESELLINGINFO 中。

附加提示：从表名中删除“信息”一词。所有表格都包含信息；将其添加到名称中只是噪音。

【讨论】：