我正在尝试建立一个与 Facebook 群组工作方式类似的网站。用户将能够加入群组，然后在这些群组中发帖。但是，我在创建关于组和帖子的数据库模式时遇到了麻烦。到目前为止，这是我的表模式：
Table 1: Users
Table 2: Groups
Table 3: Posts
每次用户在组中发帖时，posts 表都会创建一行。post 表中的该行将具有该帖子所在组的唯一 ID 以及创建该帖子的用户的唯一 ID。我担心 post 表会变得庞大，与 Groups 和 Users 表相比尤其庞大。
考虑到每个组会有很多帖子（数百到数千个），我应该为每个组创建一个新表吗？
非常感谢您对此事的任何和所有意见。
一句话，NO。您不应该创建多个表。一组表是合适的。适当地索引它应该没问题。成百上千的帖子对于数据库来说实际上是微不足道的，数据库的设计目的是能够通过适当的索引管理数百万行。表的一列应标识组所有权，但不应将其拆分为不同的表。
在最坏的情况下，您可以在表变得难以管理以适合您的磁盘空间时对其进行分区。但是，它增长到那么大的可能性非常小。
除非你的帖子数以千万计，或者帖子可能非常大，或者你的硬件非常有限，否则你应该可以使用单个 MySQL 表，只要你在 group ID 上有一个索引。
除非我们说的是百万以上的行，否则只要您正确索引表（按两个 ID 索引），您将完全没问题。
简而言之，如果数据项之间存在任何类型的依赖关系，则应创建一个新表。您可以在这里更准确地查找它：http ://en.wiktionary.org/wiki/first_normal_form
虽然它没有说明每次表变得太大时都应该创建一个新表。对于数据库管理员来说，这将是一件事情。在您的示例中，最近的帖子将比 5 个月前的帖子阅读频率更高。为了正确索引并避免数据行中的重复，您可以使用如下结构：
注）这张图说明了；i) 一个用户将发布到一个或多个组，ii) 一个组将有一个或多个用户，iii) 一个帖子将被一个组中的一个或多个用户查看。所有 3 种关系都是一对多的，用户和组之间的基数是多对多的。
此外，您可以将您的帖子（可能会随着时间的推移而增长的表格）“分组/构建”为数年、数月甚至数周。因此，您将能够说出哪个时间段，从而您也可以将此时间因素设置为您的帖子表中的日期字段，而不是单独的表。
