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

[nullcoder]

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

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

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

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

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

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

[Mitt]

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

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

[2ME]

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

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

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

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

[b821025551b]

第一次见到第一种方法，长见识了。。。

[polymerdg]

第一种不敢用 厉害

[LukeChien]

wordpress 官网还真是第一种方法，艺高人胆大

[hiboshi]

我们项目 700 多张表 看着就 头大，你们用户如果多起来 根本无法查看

[summerwar]

第一种应该是一个用户一个数据库吧，一个数据表咋放下不同的表

[kuro1]

范式可能是假的

[jydeng]

第一种肯定不行，不说用户太多表几十万张，用户的信息也不是一张表能存的了，毕竟这么多字段。

[nullcoder]

@LukeChien 啊？ Are you kidding?

[xAx]

多租户,每个租户分表或分库的方案到是不少。

但这也是按租户为单位分，按用户分真没见过。

[shadowwalker2644]

终极方案，每个字段一张表

[tabris17]

第一种也没啥不行，其实就是表的水平切分嘛

[asen477]

第一种方法不适当。
分布式数据库设计，需要做分表分库设计，通过 UID 算法去区分用户所在库或是表、
然后还有一种数据仓的设计。

[nirpis]

用户表 日志表

[vus520]

你们没有按天做的表么。嘲讽模式开启。

[BlackGrasshopper]

如果第一个方案，很好奇如果未来你们要统计某一类用户，或者特定条件的用户，你们要怎么统计

[nullcoder]

@BlackGrasshopper 用户 ID 是表名啊，多表查询？

[CruelMoon]

第一种偶见过差不多的，一家公司一个表...每个表的结构完全一样。还是号称专门搞“大数据”的人搞出来的...

[CruelMoon]

@CruelMoon #19 并且偶们的数据量很小，每个表里才几十条数据，也不像楼主说的那样。

[Tompes]

第一种见过，我们教授做过这种东西 [逃]

[nosay]

第一种仔细想来,还挺有搞头的样子

[BlackGrasshopper]

@nullcoder 要统计特定用户，全用户范围内，几万户甚至百千万你准备查几十（百千）万个表是吗。。。。。。

[zh10086]

@asen477 这种方法比较好