动态创建表以存储用户内容是一个好主意吗？

Question

我目前正在设计一个应用程序，用户可以在其中创建/加入群组，然后在群组中发布内容。我试图弄清楚如何最好地将这些内容存储在RDBMS中。

选项1：为所有用户内容创建单个表。此表中的一列将是groupID，指定发布内容的组。使用groupID创建索引，以便快速搜索特定组中的内容。所有内容读/写都将出现在这个表中。

选项2：每当用户创建新组时，我们都会动态创建一个新表。像group_content_ {groupName}这样的东西。所有内容读/写都将路由到特定于组的动态创建表。

选项1的优点：

1. 使用单个简单查询在单个表格上搜索，可以更轻松地跨多个组搜索内容。
2. 构建简单的跨表查询更容易，因为内容表是静态的并且定义明确。
3. 实现架构更改和更改索引/触发器等更容易，因为只有一个表需要维护。

选项2的优点：

1. 所有读写操作都将分布在多个表中，从而避免因大量流量占用单个表而导致的任何瓶颈（尽管如此，所有这些表仍在单个数据库中）
2. 每个表的大小都会小得多，可以更快地查找，更快的架构更改，更快的索引等等。
3. 如果我们希望将来对数据库进行分片，那么如果所有数据已经​​被分片并且＃34;那么过渡会更容易。跨越不同的桌子。

从绩效/开发/维护的角度来看，上述两个选项之间的一般建议是什么？

Answer 1

计算中的一个主要问题是过早优化。这个20多年的DBA认为，你过高估计了这些群体将要发生的IO .RDBMS非常擅长查询和编写这类信息。一组标准表。最坏的情况是，您可以稍后对其进行分区。使用一组表而不是每个用户设置，您将拥有更多的搜索功能和管理功能。

想象一下架构是否需要改变？你真的想更新数百或数千个表或写一些长脚本来解决一个平凡的问题吗？坚持使用一组表并忽略分片。相反，想想＆＃34;也许我们有一天会对表格进行分区，如果有必要的话＃34;

Answer 2

这是一个明智的选择。 （1）是要走的路。

您可以将这些列为第二种方法的优化。所有这些都是误解。见下面的评论：

  

因此，所有读取和写入将分布在多个表中   避免因大量流量袭击而导致的任何瓶颈   一张桌子（尽管如此，所有这些桌子仍然在一张桌子上   单个DB）

读取和写入可以很容易地在表中分发。唯一的问题是页面内的写冲突。这可能是一个非常小的考虑因素，除非你每秒处理超过几十个事务。

由于下一个项目（部分填充的页面），您实际上只需要一个表格和大部分填充的页面就会好得多。

  

每张表的尺寸都要小得多，以便更快地查找，   更快的架构更改，更快的索引等等

较小的表可以是性能灾难。表存储在数据页上。然后每个表都是部分填充的页面。你最终得到的是：

• 磁盘上浪费了很多空间。
• 页面缓存中浪费了大量空间 - 可用于存储记录的空间。
• 在部分填充的页面中浪费了大量的I / O读数。

  

如果我们希望将来对数据库进行分片，那么过渡会更容易   如果所有数据已经​​在不同的表中“分片”。

Postgres支持表分区，因此您可以将表的不同部分存储在不同的位置。这足以满足您传播I / O负载的目的。

Answer 3

选项1：性能=正常开发=易于维护=简单

选项2：绩效=快速发展=复杂维护=硬

我建议选择Oprion1，对于BIG表，您可以使用更好的索引或现金索引（对于某些数据库）管理性能，最后一点是没有任何帮助制作第二个选项2，因为开发维护时间是致命的因子