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

Question

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

选项1：为所有用户内容创建一个表。此表中的其中一列将是groupID，指定发布内容的组。使用groupID创建索引，以便快速搜索特定组内的内容。所有的内容读取/写入都会打到这张单独的表格。

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

优点为选项1：

1. 它更容易搜索多个论坛的内容，用一个单一的简单的查询，对单个表进行操作。
2. 由于内容表是静态的且定义明确，因此构建简单的交叉表查询会更容易。
3. 由于只有一个表来维护，因此更容易实现模式更改和对索引/触发器等的更改。

赞成选项2：

1. 所有的读取和写入操作将在众多的表来分配，从而避免可能导致大量的流量创下了单个表中的瓶颈（但无可否认，这些表仍然在一个单一的数据库中）
2. 每个表的大小都会小得多，允许更快的查找，更快的模式更改，更快的索引等。
3. 如果我们想在未来分割数据库，如果所有的数据已经被“分解”，那么就会更容易nt表。

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

Answer 1

这是一个不容易的事情。 （1）是要走的路。

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

所有读取和写入将在众多表分发，从而 避免可能导致大量的流量打 一个表中的瓶颈（但无可否认，所有这些表仍处于 single DB）

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

由于下一个项目（部分填充的页面），您实际上更适合使用大多数填充的单个表格和页面。

每个表的大小会小得多，允许更快的查找， 更快的架构变化，更快的索引，等等

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

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

如果我们要分片的DB在未来，如果所有的数据已经在不同的表“碎片化”的过渡会更容易 。

Postgres支持表分区，所以你可以在不同的地方存储表的不同部分。这应该足以满足传播I/O负载的目的。

Answer 2

计算中的一个主要罪过是优化太早。这是20年以上的DBA的观点，你高估了这些组将发生的IO。RDBMS非常擅长在一组标准表中查询和编写这种类型的信息。最坏的情况下，你可以稍后分割它们。您将拥有更多的搜索功能和管理简易性，而不是每个用户设置一组表。

想象一下，如果模式需要改变？你真的想要更新数百或数千个表，或写一些长脚本来解决一个普通的问题吗？坚持使用一组表并忽略分片。相反，想一想“如果有必要，我们可能会在某一天划分桌子”

Answer 3

选项1：性能=正常发展=易维护=易

选项2：性能=快速发展=复杂的维护=硬

我建议选择Oprion1和大桌子，您可以管理具有更好的指数或现金指标（对于某些数据库）的性能和最后一件事情没有什么帮助使第二个选项2，因为开发维护时间是致命的因素