我正在建模一个系统，该系统将在各种实体类型（Reports、Reviews 和 Collections）中获得“赞成票”。
这是仅有的三个可以投票的实体，但未来可能还会有更多。
目前，db 架构有ReportUpvotes、ReviewUpvotes 和CollectionUpvotes。
我想知道将所有这些表放在一个 Upvotes 表中是否会更好，并带有 Type 的枚举。
在评估此类决定时我应该考虑什么？
【问题讨论】：
标签： database-design schema normalization
在一张表中存储相同类型的实体（Upvotes）的想法对我来说非常有意义。然而，它可以以不同的方式实现。蝙蝠的权利我可以告诉3种方式。
问题中提出的第一个（除非我误解了）会导致多态关联，这种做法通常被认为是不好的。如果我错了，请纠正我，但您似乎想要CREATE TABLE Upvotes (..., type enum ('Report','Review',...), entity_id int) 之类的东西，其中entity_id 是指基于type 列的值的Report、Review 等表之一。如果没有触发器，您将无法强制执行此类约束。
其次是专属弧线。更好的方法（可以强制执行参照完整性），但仍然很丑陋。如果你这样走，你会有类似的东西
CREATE TABLE Upvotes(..., report_id INT , review_id INT, ....,
CONSTRAINT FK_REPORT FOREIGN KEY (report_id) REFERENCES Report(report_id),
CONSTRAINT FK_REPORT FOREIGN KEY (review_id) REFERENCES Review(review_id)
);
首先，您需要确保（report_id、review_id 等）中只有一个对于任何行都不为空。其次，添加可以投票的新实体类型意味着将新列添加到Upvotes。
第三种方式是“共同父母”方式。您正在创建一个新表，例如 UpvotableEntity（坏名，仅用于说明）。然后使其成为现有 ReportUpvotes、ReviewUpvotes 和 CollectionUpvotes 的父表。最后，Upvotes 表存储upvotable_entity_id。
【讨论】：
就像在软件开发中一样，需求应该强烈地影响你应该做什么。
您是否需要能够将所有点赞/赞一起显示或显示在一个地方？
您是否设想添加更多类型的点赞？
对这两个回答“是”会让我倾向于一张桌子。
除此之外，就像在软件开发中一样，如果表在结构和用途上非常相似，则可以将它们“重构”为单个表。出于这个原因，我倾向于使用一张桌子。
【讨论】：