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