一张大桌子还是多张桌子？

Question

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

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

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

考虑到每组会有很多帖子（数百到数千），我应该为每个组创建一个新表吗？

对此事的任何和所有意见都将不胜感激。

Answer 1

总之，没有。您不应该创建多个表。一组表是合适的。适当地索引它应该没问题。数以千计的帖子实际上与数据库无关，数据库旨在通过适当的索引管理数百万行。表的一列应标识组所有权，但不应将其拆分为不同的表。

在最糟糕的情况下，当桌面变得难以管理时，您可以对桌面进行分区以适应您的磁盘空间。然而，它增长的可能性非常小。

Answer 2

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

Answer 3

除非我们说的是百万行，否则只要你正确地索引表（两个ID都是索引），你就会完全没问题。

Answer 4

放入简单化的视图，如果数据项之间存在任何类型的依赖关系，则应创建新表。您可以在此处更精确地查找：http://en.wiktionary.org/wiki/first_normal_form

虽然每次表变得太大时都应该创建一个新表，但它没有说明。这将是数据库管理员的事情。在您的示例中，最近的帖子比5个月前写的更频繁。为了正确编制索引并避免数据行中的重复，您可以使用如下结构：

注意）这个图说明了; i）一个用户将发布到一个或多个组，ii）一个组将具有一个或多个用户，iii）一个帖子将由组中的一个或多个用户查看。所有3个关系都是一对多的，用户和组之间的基数是多对多的。

此外，您可以将您的帖子“分组/结构化” - 可能随时间增长的表格 - 分为几年，几个月甚至几周。那么你就可以说出哪个时间段，你也可以把这个时间因素作为你的帖子表中的日期字段，而不是单独的表。