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

Question

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

选项1:为所有用户内容创建单个表.此表中的一列将是groupID,指定发布内容的组.使用groupID创建索引,以便快速搜索特定组中的内容.所有内容读/写都将触及此单个表.

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

方案1的优点:

1. 使用单个简单查询在单个表上操作,可以更轻松地跨多个组搜索内容.
2. 构建简单的跨表查询更容易,因为内容表是静态的并且定义良好.
3. 实现模式更改和更改索引/触发器等更容易,因为只有一个表可以维护.

方案2的优点:

1. 所有读写操作都将分布在多个表中,从而避免了大量流量冲击单个表所导致的任何瓶颈(尽管如此,所有这些表仍然在一个数据库中)
2. 每个表的大小都会小得多,从而可以更快地查找,更快的模式更改,更快的索引等
3. 如果我们希望将来对数据库进行分片,那么如果所有数据已经​​在不同的表中"分片",则转换会更容易.

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

Answer 1

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

想象一下,架构是否需要改变？你真的想更新数百或数千个表或写一些长脚本来解决一个平凡的问题吗？坚持使用一组表并忽略分片.相反,想一想"如果有必要,我们可能会在某一天对表格进行分区"