一个大表还是多个表？

Question

我正在尝试建立一个网站，其设计与Facebook小组的工作方式相似。 用户将能够加入组，然后在这些组中发布。 但是，我在创建关于组和帖子的数据库架构时遇到了麻烦。 到目前为止，这是我的表架构：

Table 1: Users
Table 2: Groups
Table 3: Posts

每当用户在组中发布时，posts表都会创建一行。 帖子表中的该行将具有该帖子所属的组的唯一ID，以及创建该帖子的用户的唯一ID。 我担心的是，发布表将变得庞大，尤其是与“组”和“用户”表相比。

考虑到每个小组有很多职位（数百到数千个），我应该为每个小组创建一个新表格吗？

对此，任何和所有投入将不胜感激。

Answer 1

一言以蔽之。 您不应该创建多个表。 一个组表是合适的。 适当索引它应该没问题。 对于数据库来说，成百上千的帖子几乎是什么，它旨在通过适当的索引来管理数百万行。 表的一列应标识组的所有权，但您不应将其拆分为其他表。

在最坏的情况下，当表太大而无法容纳磁盘空间时，您可以对表进行分区。 但是，它增长到如此之大的可能性非常小。

Answer 2

除非您有成千上万的帖子，或者帖子可能很大，或者您的硬件非常有限，否则只要使用组ID索引，就可以使用单个MySQL表。

Answer 3

除非我们谈到百万条以上的行，否则只要您正确索引表（通过两个ID进行索引）就可以了。

Answer 4

简而言之，如果数据项之间存在某种依赖关系，则应创建一个新表。 您可以在此处更精确地查找它： http : //en.wiktionary.org/wiki/first_normal_form

它没有说明每次表太大时都应创建一个新表。 对于数据库管理员来说，那是一件好事。 在您的示例中，与5个月前撰写的文章相比，最新文章的阅读频率更高。 为了正确建立索引并避免在数据行中重复，可以使用如下结构：

注）此图说明了这一点； i）一个用户将发布到一个或多个组，ii）一个组将拥有一个或多个用户，iii）一个帖子将被一组中的一个或多个用户查看。 这三个关系都是一对多的，并且用户和组之间的基数是多对多的。

而且，您可以将您的帖子“分组/组织”，该表格可能随着时间的推移而增长，可以分成数年，数月甚至数周。 这样一来，您便可以说出在哪个时间段，您还可以将此时间因素设为帖子表中的日期字段，而不是单独的表。