具有相同架构的多个表或具有多个外键的 1 个表？

Question

我正在开发一个 ASP.NET MVC 4 应用程序，其中每个“级别”都有一个添加费用的选项。假设我有一家公司可以有很多活动（一对多），以及有很多产品的活动（一对多）。 [使用 DB 优先设计]

公司、活动和产品都可以有一个与之关联的“费用”列表，并且费用数据是相同的 [名称、价值、FK 等]

我目前正在使用具有关联表的外键的“CompanyFee”、“CampaignFee”和“ProductFee”表。 [除FK关系外的相同表]

是否有一个“费用”表，其中每个表都有一个外键列，可以有费用。所以“FeeTable”将是 [name, value, CompanyID(FK), CampaignID(FK), ProductID(FK), etc]

这意味着如果 ProductID 是唯一具有值的 FK，而其他 FK 为 null，则它将被视为“ProductFee”。

将这些表分开是最佳做法吗？这两种结构的其他含义是什么？

Answer 1

此讨论仅涉及数据建模，而不涉及 EF 或 ASP.NET MVC 考虑事项。我看到 2 个选项。两者都是正确的。选项 1 要求费用的 PK 是 FeeID，并且 CompanyID_FK 不能为空，而其他 2 个 FK 应该可以为空。

如果您想让您的模型灵活，我建议您使用选项 2。

但是，如果您不打算扩展模型，或者您在这方面没有进一步的要求，那么选项 1 是一个有效的选择，它使用的表数量更少，并且需要的代码行数也更少。

选项 1 的问题在于，如果将来您创建与费用表相关的表，您将遇到奇怪的情况，例如：

A.如果您需要一个“费用说明”表，则必须为所有 3 项费用提供 1 个表。这不好，因为某些描述可能不适用于所有费用类型。

B.如果您需要一个“费用审批者”表，同样，您必须为所有 3 种费用类型的审批者提供 1 个表。

使用选项 2，您不会遇到上述问题。

选项 2 的明显问题是额外的表格数量和额外的代码行。

虽然您没有提供大小信息，但根据域的性质，我认为大小不会导致性能问题。