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

128 天前
 lllei

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

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

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

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

5109 次点击
所在节点    数据库
22 条回复
Froward
128 天前
垂直分表
drymonfidelia
128 天前
mongodb 可以
inshua
128 天前
pg 多年前就有 jsonb
justfindu
128 天前
很久很久以前用过一个 laravel-meta , 1 - n meta ,
mark2025
128 天前
简单查询的非关键字段可以丢 pg 的 jsonb 字段中,随时可以更新,并且还可以给任意(子)字段键名添加索引
justNoBody
128 天前
只要不做统计,我觉得 jsonb 就很完美呀
lllei
128 天前
咦,原来这么多人支持 jsonb 吗,我原来还以为是小众做法。
lllei
128 天前
但我是感觉飞书应该是垂直分表 或 mongodb ?
nothingistrue
128 天前
第一,没人规定不能改数据库,给表加几列,是非常简单的事。
第二,如果为了性能考虑,不方便给用户表加列,那就把用户表拆成主要信息表,跟次要信息表,只要不参与检索的都扔到次要表,然后次要表加列。
第三,属性超过三十个,并且还基本都是万年不用一次的属性的时候,那它就没必要用到「列」这种级别的数据了,组装成 JSON 后,作为字符串存到一列里面,部分数据库还可以直接用 JSON 类型( Mysql 不要用,坑太多)。

还有一种数据结构,纵表,有用,但是很少回去用它,就懒得说了。
nothingistrue
128 天前
如果你还有检索需求,并且还是随便挑几个属性去检索的需求,那么这时候就必须 mongodb 或者其他对象数据库了,JSON 都顶不住,关系数据库的纵表方案,想都不要想。
sujin190
128 天前
用户表这种作为核心流程的表,基本设计原则应该是核心字段横表且固定不轻易修改,非核心字段纵表 KV 动态扩展,也就是常规用户信息都会分为 user 表和 profile 表,虽然数据库表加字段确实很容易,但是核心表三天两头改字段真的是在给自己加很多班,以及上面什么自定义字段什么存 json 什么 mongodb 动态都很坑,毕竟用户表作为核心流程几乎串联了整个系统,必需稳定且可靠,关于哪些是核心字段哪些是非核心字段就看设计功力了
sujin190
128 天前
或者复杂的还可以进一步分成用户表、账户表、档案表和通行证表,你说的工位,工号,分组号这种会动态变化的一般都属于档案信息,基于用户档案信息通用性相关及查询效率优化,用户档案还可能进一步分成基础档案表和扩展档案表,业务逻辑一般都是用用户表来串联的,这个表几乎不可能会修改,也保证了各业务系统可以可靠依赖用户信息,而档案信息其它业务系统需要使用也必需直接从用户系统通过接口实时获取,这样档案数据结构修改就要容易很多了影响也小
IanLeto
128 天前
出海做准备吧,欧洲国家对产品团队女性占比有要求的,尤其产品发布会,电影发布会这种对外宣发类工作。
IanLeto
128 天前
@IanLeto 回错主题了~~
encro
128 天前
user 的 account 表和 profile 表分开来。
encro
128 天前
增加字段现在也可以无锁加了,非常方便。
lllei
128 天前
@sujin190 学习了🙏
lllei
128 天前
@nothingistrue 学习了
louisxxx
127 天前
最简单的就是垂直分表
KJR5OR04CnCiWf02
126 天前
mongodb 我知道,另一种大家说的垂直分表方案是怎么做的?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1053362

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX