很好奇飞书的数据库表是咋设计的

[lllei]

比如说我有一个用户管理系统，但随着业务增长，可能需要给用户增加字段。比如说增加：工位，工号啥的。

那如果我是把用户相关信息存到用户表上，那是要改表吗？

像飞书这种，一个用户存储的相关信息也很多：手机号，邮箱，工位，工号，分组号，自定义属性……

这些繁杂的属性是怎么存储的呢？

[Froward]

垂直分表

[drymonfidelia]

mongodb 可以

[inshua]

pg 多年前就有 jsonb

[justfindu]

很久很久以前用过一个 laravel-meta , 1 - n meta ,

[mark2025]

简单查询的非关键字段可以丢 pg 的 jsonb 字段中，随时可以更新，并且还可以给任意（子）字段键名添加索引

[justNoBody]

只要不做统计，我觉得 jsonb 就很完美呀

[lllei]

咦，原来这么多人支持 jsonb 吗，我原来还以为是小众做法。

[lllei]

但我是感觉飞书应该是垂直分表 或 mongodb ？

[nothingistrue]

第一，没人规定不能改数据库，给表加几列，是非常简单的事。
第二，如果为了性能考虑，不方便给用户表加列，那就把用户表拆成主要信息表，跟次要信息表，只要不参与检索的都扔到次要表，然后次要表加列。
第三，属性超过三十个，并且还基本都是万年不用一次的属性的时候，那它就没必要用到「列」这种级别的数据了，组装成 JSON 后，作为字符串存到一列里面，部分数据库还可以直接用 JSON 类型（ Mysql 不要用，坑太多）。

还有一种数据结构，纵表，有用，但是很少回去用它，就懒得说了。

[nothingistrue]

如果你还有检索需求，并且还是随便挑几个属性去检索的需求，那么这时候就必须 mongodb 或者其他对象数据库了，JSON 都顶不住，关系数据库的纵表方案，想都不要想。

[sujin190]

用户表这种作为核心流程的表，基本设计原则应该是核心字段横表且固定不轻易修改，非核心字段纵表 KV 动态扩展，也就是常规用户信息都会分为 user 表和 profile 表，虽然数据库表加字段确实很容易，但是核心表三天两头改字段真的是在给自己加很多班，以及上面什么自定义字段什么存 json 什么 mongodb 动态都很坑，毕竟用户表作为核心流程几乎串联了整个系统，必需稳定且可靠，关于哪些是核心字段哪些是非核心字段就看设计功力了

[sujin190]

或者复杂的还可以进一步分成用户表、账户表、档案表和通行证表，你说的工位，工号，分组号这种会动态变化的一般都属于档案信息，基于用户档案信息通用性相关及查询效率优化，用户档案还可能进一步分成基础档案表和扩展档案表，业务逻辑一般都是用用户表来串联的，这个表几乎不可能会修改，也保证了各业务系统可以可靠依赖用户信息，而档案信息其它业务系统需要使用也必需直接从用户系统通过接口实时获取，这样档案数据结构修改就要容易很多了影响也小

[IanLeto]

出海做准备吧，欧洲国家对产品团队女性占比有要求的，尤其产品发布会，电影发布会这种对外宣发类工作。

[IanLeto]

@IanLeto 回错主题了～～

[encro]

user 的 account 表和 profile 表分开来。

[encro]

增加字段现在也可以无锁加了，非常方便。

[lllei]

@sujin190 学习了🙏

[lllei]

@nothingistrue 学习了

[louisxxx]

最简单的就是垂直分表

[KJR5OR04CnCiWf02]

mongodb 我知道，另一种大家说的垂直分表方案是怎么做的？

[drymonfidelia]

@ppppppp123
建一个表，三个字段
userid=111
field=name
value=abc

[KJR5OR04CnCiWf02]

垂直分表方案 是从哪里流行来的？