这是一个创建于 2583 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在的设计是：
为每一个用户建一个表，然后表名就是用户 ID
表里的数据是用户的所有历史
业务上用户肯定会持续增长，这样数据库的表就会越来越多
另一种设计是
不同用户的同类型的业务放到一个表，一个类型建一个表
这样就需要加一列用户 ID，会有非常多的行用户 ID 是相同的（一个用户一个类型几万条）
而且为了研究一个用户的历史，可能需要增加查询的复杂程度
或者建视图，而类型可能也会慢慢增加。
其他可能的缺点还没有想到。
看看有没有大佬有改进的建议？
为每一个用户建一个表，然后表名就是用户 ID
表里的数据是用户的所有历史
业务上用户肯定会持续增长，这样数据库的表就会越来越多
另一种设计是
不同用户的同类型的业务放到一个表，一个类型建一个表
这样就需要加一列用户 ID，会有非常多的行用户 ID 是相同的（一个用户一个类型几万条）
而且为了研究一个用户的历史，可能需要增加查询的复杂程度
或者建视图，而类型可能也会慢慢增加。
其他可能的缺点还没有想到。
看看有没有大佬有改进的建议？
第 1 条附言 · 2017-12-01 16:23:10 +08:00
补充一下，说的“用户”不能算是真的用户，实际上是某种实体。
这也是同事从 E-R 角度的考虑，另一个考虑是这些数据存入之后更多是 OLAP 类型的应用
目前“用户”规模很小（ 50 上下），每次事件会有几万条数据，全放在一起也就是近百万条。
以后“用户”规模可能上几千上万。
这些数据是从第三方软件导出的，从他们项目文件下的 frm 文件来看。
他们是每次事件，建一个表。这也是第一种设计的参考之一。
这里的事件一天最多三次。
一次事件一个表或者一个“用户”一个表如果是中间表，不知道是否可取一些？？
这也是同事从 E-R 角度的考虑，另一个考虑是这些数据存入之后更多是 OLAP 类型的应用
目前“用户”规模很小（ 50 上下），每次事件会有几万条数据，全放在一起也就是近百万条。
以后“用户”规模可能上几千上万。
这些数据是从第三方软件导出的，从他们项目文件下的 frm 文件来看。
他们是每次事件，建一个表。这也是第一种设计的参考之一。
这里的事件一天最多三次。
一次事件一个表或者一个“用户”一个表如果是中间表，不知道是否可取一些？？
 |
1
Mitt 2017-12-01 15:24:42 +08:00
第一种不存在的
第二种可以接受 可以分表分库 但不是第一种那个分法 |
 |
2
2ME 2017-12-01 15:26:13 +08:00
第一种设计是什么操作 几万个用户就几万个表了 有时候用 GUI 去读个 table 列表都卡死了.. = =
提数据库设计这种需求首先要写明你当前业务或者用户的规模 防止过度设计 一个还没上线的业务你设计几亿用户的表结构,数据库架构也没啥用阿 用户没达到一定量级的话你用户用你第二种方法 可以用 或者所有用户都集中在一张表就可以了 加一个 type 字段去区分 用户历史之类的用 ORM 关系映射 频繁修改的字段分离出来另建表 .. 对数据库没有什么太深的理解 仅供参考.. 有错误 dalao 指出 好跟着学习一哈 |
 |
3
b821025551b 2017-12-01 15:27:10 +08:00
第一次见到第一种方法，长见识了。。。
|
 |
4
polymerdg 2017-12-01 15:30:07 +08:00
第一种不敢用 厉害
|
 |
5
LukeChien 2017-12-01 15:33:19 +08:00 via Android
wordpress 官网还真是第一种方法，艺高人胆大
|
 |
6
hiboshi 2017-12-01 15:43:56 +08:00
我们项目 700 多张表 看着就 头大，你们用户如果多起来 根本无法查看
|
 |
7
summerwar 2017-12-01 15:51:25 +08:00
第一种应该是一个用户一个数据库吧，一个数据表咋放下不同的表
|
 |
8
kuro1 2017-12-01 15:56:39 +08:00
范式可能是假的
|
 |
9
jydeng 2017-12-01 15:57:02 +08:00
第一种肯定不行，不说用户太多表几十万张，用户的信息也不是一张表能存的了，毕竟这么多字段。
|
 |
11
xAx 2017-12-01 16:03:22 +08:00
多租户,每个租户分表或分库的方案到是不少。
但这也是按租户为单位分，按用户分真没见过。 |
 |
12
shadowwalker2644 2017-12-01 16:08:12 +08:00 via Android
终极方案，每个字段一张表
|
 |
13
tabris17 2017-12-01 16:09:27 +08:00
第一种也没啥不行，其实就是表的水平切分嘛
|
 |
14
asen477 2017-12-01 16:11:02 +08:00
第一种方法不适当。
分布式数据库设计，需要做分表分库设计，通过 UID 算法去区分用户所在库或是表、 然后还有一种数据仓的设计。 |
 |
15
nirpis 2017-12-01 16:14:15 +08:00
用户表 日志表
|
 |
16
vus520 2017-12-01 16:48:32 +08:00
你们没有按天做的表么。嘲讽模式开启。
|
 |
17
BlackGrasshopper 2017-12-01 16:50:13 +08:00
如果第一个方案，很好奇如果未来你们要统计某一类用户，或者特定条件的用户，你们要怎么统计
|
 |
18
nullcoder OP @BlackGrasshopper 用户 ID 是表名啊，多表查询？
|
 |
19
CruelMoon 2017-12-01 17:13:25 +08:00
第一种偶见过差不多的，一家公司一个表...每个表的结构完全一样。还是号称专门搞“大数据”的人搞出来的...
|
 |
21
Tompes 2017-12-01 17:15:48 +08:00
第一种见过，我们教授做过这种东西 [逃]
|
 |
22
nosay 2017-12-01 17:18:46 +08:00
第一种仔细想来,还挺有搞头的样子
|
|
23
BlackGrasshopper 2017-12-01 17:26:01 +08:00
@nullcoder 要统计特定用户，全用户范围内，几万户甚至百千万你准备查几十（百千）万个表是吗。。。。。。
|
Select Language