我想为几个不同的实体/表（例如文章、博客文章、用户）实现投票系统。
什么是最好/更有效的方法？：
创建一个投票表来存储所有实体的所有投票？
投票
- vote_id
- user_id
- 类型（文章、博文或用户）
为每个实体创建一个投票表？ votes_articles, votes_blogposts, votes_users
我看到的是： 第一个选项将产生一个更大的表，并且我需要在查询中包含一个附加字段。如果需要，可以为更多实体轻松扩展更通用的表，并且一切都是集中的。 （可以使用通用函数来检索/插入/更新表。）
第二个选项将导致较小的表；查询速度更快？但不一定更好维护。
【问题讨论】：
标签： mysql database performance
第二种方法有很多优点。据推测，投票实际上是针对实体的，因此您在每个表中还有一个 id 指向文章、博客文章或任何正在投票的内容。在标准 SQL 数据库中，您希望有对其他表的外键引用，而每个实体一个表的方法提供了这种能力。
您可以修改第一种方法来执行此操作。但是，这将需要为每个可能的实体提供一个单独的列。然后，您将失去添加新实体的轻松灵活性。
第一种方法何时有利？首先，维护有效的外键引用并不重要。而且，当您经常希望将选票汇总为 votes 时。那么，用户今天投票了多少次无论他/她投了什么票？用户 A 和用户 B 共有多少票无论他们投了什么票？明白了。如果votes 开始表现得像自己的实体，那么它应该拥有自己的表。
我碰巧认为您的问题突出了 SQL 和关系数据库的一个主要弱点。这是一个希望不同实体从一个类“继承”特性的示例（借用 OO 世界的术语）。如果您可以指定一个新实体从另一个实体（例如“Votable”）继承属性，那不是很好吗？哦，没关系，这不是流行数据库的真实世界。至少今天不会。
编辑：
如果您关心性能，请不要使用修改后的第一种方法 - 即，为每个可能的实体单独列。通常，主键是 4 字节整数。这些（至少在大多数数据库中）将占用四个字节，无论该列是否具有 NULL 值。因此，一个具有三个实体列的表（非常粗略地近似）是每个实体专用的三个表大小的三倍。这种浪费的空间只会减慢查询处理速度。
如果您只打算拥有两个或三个实体，也许这没什么大不了的。但是，一旦超出了您的一只手所能指望的范围，这确实是对空间、内存和处理能力的浪费。
【讨论】：