为每个用户单独创建数据库表是否合理？实现相关问题咨询

1. 为每个用户单独创建一张table是否为合理的设计方案？ #

99%的常规Web项目场景下，这是典型的反模式设计，完全不合理。

• 扩展性极差：如果用户量涨到1万、10万级别，库内会生成数万甚至数十万张表，会直接拖垮数据库元数据管理、查询优化器的性能，后续备份、迁移、故障排查的成本会高到无法接受。
• 迭代成本极高：后续如果要给用户关联的数据加字段、调整索引，需要遍历所有用户对应的表挨个执行变更，极易出现漏改、错改问题；但凡要做跨用户统计、全局数据筛选，实现复杂度会飙升好几个量级。
• 常规场景的成熟方案非常简单：建一张公共用户表存储所有用户基础信息，其他和用户关联的业务表统一加user_id字段关联用户表主键即可，这是行业通用的经过几十年验证的设计，不管是查询、维护还是扩展都没有额外成本。
  只有极特殊场景（比如单用户数据量达到TB级、有极强的物理数据隔离要求）才会考虑类似拆分方案，而且也不会按普通C端用户维度拆分，普通业务项目完全没必要碰。

2. 若该方案可行，应当如何实现？ #

如果确实有特殊场景必须用这套方案，核心是在应用层实现动态表管理逻辑：

• 用户注册流程完成后，在应用代码中拼接建表SQL，表名建议带上用户唯一ID做后缀，比如user_private_data_1001，避免表名冲突；
• 所有用户私有数据的查询请求，都要在应用层先校验当前请求的用户ID，动态拼接对应表名再执行SQL，绝对不能让前端传表名相关参数，避免出现SQL注入漏洞；
• 单独编写表结构升级逻辑，后续表结构变更时，要遍历所有用户对应的表挨个执行更新，同时要做好部分表更新失败的异常兼容。

3. 是否可以将这类表创建在名为"users"的folder中？ #

主流关系型数据库没有操作系统层面“文件夹”存储表的概念，你可以用数据库自带的逻辑隔离能力实现类似效果：

• PostgreSQL这类支持多Schema的数据库，可以单独创建一个名为users的Schema，把所有用户专属表都建在这个Schema下，建表示例：CREATE TABLE users.user_private_data_1001 (...)；
• MySQL中Schema和数据库是等价概念，你可以单独创建一个名为users的数据库，把这类表统一存在这个库中，和其他公共业务表做隔离。

4. 是否支持像遍历array那样扫描所有该类表？ #

没有数据库原生的直接遍历支持，可以间接实现，但性能和维护性都很差：

• 第一步先查询数据库自带的元数据表，捞取所有符合命名规则的表名，比如查询information_schema.tables系统表，筛选出表名前缀为user_private_data_的所有表名；
• 第二步在应用层代码中循环遍历拿到的表名列表，挨个拼接查询SQL执行，最后把所有表的返回结果汇总到一起。
• 注意：如果表的数量较多，这种全表扫描操作会给数据库带来极大的性能压力，很容易把数据库打挂，生产环境尽量不要执行这类操作。

内容的提问来源于stack exchange，提问作者JustARandomProgrammer