[数据库设计]怎样改进一个用户一个表的设计？

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 3261 days ago, the information mentioned may be changed or developed.

现在的设计是：
为每一个用户建一个表，然后表名就是用户 ID
表里的数据是用户的所有历史
业务上用户肯定会持续增长，这样数据库的表就会越来越多

另一种设计是
不同用户的同类型的业务放到一个表，一个类型建一个表
这样就需要加一列用户 ID，会有非常多的行用户 ID 是相同的（一个用户一个类型几万条）
而且为了研究一个用户的历史，可能需要增加查询的复杂程度
或者建视图，而类型可能也会慢慢增加。
其他可能的缺点还没有想到。

看看有没有大佬有改进的建议？

Supplement 1 · Dec 1, 2017

补充一下，说的“用户”不能算是真的用户，实际上是某种实体。
这也是同事从 E-R 角度的考虑，另一个考虑是这些数据存入之后更多是 OLAP 类型的应用
目前“用户”规模很小（ 50 上下），每次事件会有几万条数据，全放在一起也就是近百万条。
以后“用户”规模可能上几千上万。

这些数据是从第三方软件导出的，从他们项目文件下的 frm 文件来看。
他们是每次事件，建一个表。这也是第一种设计的参考之一。
这里的事件一天最多三次。

一次事件一个表或者一个“用户”一个表如果是中间表，不知道是否可取一些？？

用户

建视图

表名

行用户

24 replies • 2017-12-02 11:52:45 +08:00

Mitt

Dec 1, 2017

第一种不存在的
第二种可以接受

可以分表分库但不是第一种那个分法

2ME

Dec 1, 2017

第一种设计是什么操作几万个用户就几万个表了有时候用 GUI 去读个 table 列表都卡死了.. = =

提数据库设计这种需求首先要写明你当前业务或者用户的规模防止过度设计一个还没上线的业务你设计几亿用户的表结构,数据库架构也没啥用阿

用户没达到一定量级的话你用户用你第二种方法可以用或者所有用户都集中在一张表就可以了加一个 type 字段去区分用户历史之类的用 ORM 关系映射频繁修改的字段分离出来另建表 ..

对数据库没有什么太深的理解仅供参考.. 有错误 dalao 指出好跟着学习一哈