建模提升投票/点赞-每种类型一个表，或者一个大表

Question

我正在为一个系统建模，该系统将在各种实体类型（Reports、Reviews和Collections）中具有"支持票"。

这是仅有的三个可以被投票支持的实体，尽管未来可能会有更多。

目前，数据库模式有ReportUpvotes、ReviewUpvotes和CollectionUpvotes。

我想知道是否最好将所有这些表合并到一个Upvotes表中，并为Type添加一个枚举。

在评估这种决策时，我应该考虑什么？

Answer 1

将相同类型的实体（Upvotes）存储在一个表中的想法对我来说非常有意义。然而，它可能以不同的方式实现。在击球的右边，我可以说出三种方法。

问题中提出的第一个（除非我误解了）会导致多态关联，这种做法通常被认为是糟糕的。如果我错了，请纠正我，但您似乎想要类似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等）中只有一个不为null。其次，添加新的可向上投票的实体类型意味着向Upvotes添加新列。

第三种方法是"共同父母"方法。您正在创建一个新表，例如UpvotableEntity（名称不正确，仅用于说明）。然后使其成为现有ReportUpvotes、ReviewUpvotes和CollectionUpvotes的父表。最后，Upvotes表存储upvotable_entity_id。

Answer 2

就像在软件开发中一样，需求应该强烈影响你应该做什么。

你需要能够一起或在一个地方显示所有的赞成票/点赞吗？

你打算增加更多类型的赞成票吗？

对这两个问题中的任何一个回答"是"都会让我倾向于一张桌子。

除此之外，就像在软件开发中一样，如果表在结构和用途上非常相似，则可以将它们"重构"为一个表。同样出于这个原因，我倾向于拥有一张单人桌。