我在不同的公司都遇到同一个问题，就是如何用统一的用户表来存储不同业务的用户

[Yuicon]

比如一个后台有公司自己的管理员、运维等等 又有商户用户 商户的员工之类的

我在好几家公司看到都是不同身份单独建表 后面写业务痛苦万分 比如登录、权限

我后面想改成用统一的用户表 又有不同身份的用户需要的字段不一样的问题 之前我是不删原来的身份表来当子表存放特殊字段 但是有同步数据的麻烦

现在换了家公司 遇到同样的问题 现在我的方案是统一用户表 增加一个 json 字段来存放身份自定义字段 这样就有搜索问题 准备用 es 这类来解决

不知道大家有没有刚好的方案

[Yuicon]

10 分钟了 大佬们

[TORYOI]

https://mtide.net/%E5%B9%B3%E5%8F%B0%E7%BA%A7SAAS%E6%9E%B6%E6%9E%84%E7%9A%84%E5%9F%BA%E7%A1%80-%E7%BB%9F%E4%B8%80%E8%BA%AB%E4%BB%BD%E7%AE%A1%E7%90%86%E7%B3%BB%E7%BB%9F.html

[AngryMagikarp]

基本用户表中加入一个身份字段，比如 role，然后针对每一种 role 创建一个信息表。

用 JSON 来存不方便查询、更新等操作。

[yinzhili]

主表+扩展表 这样的做法比较常见

[sagaxu]

不要统一
不要统一
不要统一

[Yuicon]

@sagaxu 为啥啊 我感觉统一有很多好处

[donnior]

keycloak 之类的方案能满足你的需求不？

[Yuicon]

@donnior 功能也不复杂 没必要引入一个黑盒 自己实现更好

[fighterlyt]

@Yuicon
不要混淆了业务复杂度和技术复杂度，技术人员能够调整或者掌控的只有技术复杂度。不同层次的问题，需要在不同层次上解决。用户的登录问题或者说权限问题，引入专门的策略引擎，就可以解决这个问题了，推荐 OPA.

[Yuicon]

@fighterlyt 我觉得这部分是可以通用的 微服务化后 一个统一的用户表是刚需

[fighterlyt]

@Yuicon 无论如何,内聚不是体现在表上的，而是服务,数据只是载体，服务才是业务

[janwarlen]

好文

[wushigejiajia01]

这不就是用 基本信息表 + 扩展信息表
两张表就可以了啊

用户姓名、id 、身份类型之类放基础信息表，各个身份独有信息放扩展表

缺陷就是有多个身份就会存在多个扩展表

[chendy]

用户基本信息统一，不同业务不同权限在各自的数据里做

[xuanbg]

不同身份仅仅是不同应用的不同角色而已，只要角色表加一个 appId 字段就行了。https://github.com/xuanbg/insight_auth
这个项目的表结构楼主可以参考一下

[icerhe]

就你描述的业务而言.运营公司内部的员工(管理,运维等)和外部商户的员工(库管,业务员)就不是一类业务不是一类对象, 本来就不该统一,更不该放在一张表里.
如果你发现不同的用户很难统一很难通用, 那么很可能他们就不能统一不该通用.
退一万步讲, 就算未来有一天你发现两种用户可以统一, 把分离的用户表和业务代码合并所需的重构工作量,也远小于把原来合并的用户表和代码拆开的工作量,

咱们码农要了解业务, 根据业务现实而不是一些死板的"设计原则"来设计系统, 业务现实是第一位的, 应该是设计原则帮助我们更好的实现业务而不是反过来让业务适应设计原则, 那是削足适履

[icerhe]

如果权限是全站统一的, 那么权限可以一张表里统一管理, 如果用户本身就不同类,那么就不要强行把用户塞在一起.用户表分离,权限统一管理即可

[keepeye]

用户可以统一，但不是把所有业务的用户资料都往一个表里面塞。可以参考下 ucenter

[magygt]

这大概是大厂都在建中台的原因吧。
具体一点，一张表的方案，初期可能是技术友好，实现起来快。多张表的方案，业务友好，边界清晰，初期复杂度高，但后期拓展性更好。
而中台抽象共性，具体解决特性。可以理解成对业务方是一张表。

[bsg1992]

业务不一样 不需要统一