未分類
26 5 月 2020

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

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

資深大佬 : Yuicon 4

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

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

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

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

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

大佬有話說 (39)

  • 主 資深大佬 : 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

    业务不一样 不需要统一

  • 資深大佬 : falcon05

    @wushigejiajia01 没错，WordPress 就是这样实现的，一张 user 表，一个 user_meta 表。理论上可以无限扩展，缺点就是经常要关联查询

  • 資深大佬 : tuochenlyu

    建议业务不明确或变化快时，能不拆就不拆，通过附属表的一个一段区分业务类型，数据库字段名称用 string1,int1 之类的代替，再用 orm 映射成有意义的名称。这样多个附属表就合并成了一个表。
    后面业务量大或者业务稳定明确，再拆分也不迟。

  • 資深大佬 : janxin

    只有用户身份标识统一，其他的无需统一

  • 資深大佬 : zxcslove

    人员，身份，等级，部门，这些可以认真模仿一下现实世界。

  • 資深大佬 : night98

    是这样的，如果你的业务需求是单个用户账号可能存在多个角色时，那么放在一张表是比较合适的场景，比如一个商户账号既是商户，又是运维。这种情况下就比较适合单表存储，另外开设角色表和角色对应的权限表。
    而如果你的业务需求是各个角色涉及的业务操作完全不一样，那么直接开多个表即可，将不同用户账户的服务完全隔离开，比如商户方单独有商户的服务，用户单独用户的服务，运维单独运维的服务，这样既减少了鉴权的请求，同时也更容易理解数据的边界。

  • 資深大佬 : saulshao

    建立一个基础的用户表，这个表只存放所有角色都需要用到的字段，例如名字，密码，电子邮件，手机号……
    其余的字段按照不同的角色划分，例如供应商表存放发货地址，收款账号，等等。
    我之前也一直觉得，扩展性的意思是见了一个表用一辈子，有业务需求的时候不改最佳。
    但是这个世界是变化的，扩展性最佳的例子，其实是建立起一个额外的表，然后对应的 CRUD 。

  • 資深大佬 : akira

    维护系统的人 和 使用系统的人，这 2 类账号最好还是分离

  • 資深大佬 : jones2000

    用 mongo， 扩展也方便。

  • 資深大佬 : jugelizi

    这是到处挖坑啊

  • 資深大佬 : LokiSharp

    单个表大了索引会很慢的

  • 資深大佬 : xy90321

    强行统一意义何在
    在你觉得都是用户（因为最终是对应具体的物理人？？？），可是换个角度看根本就不是不同 entity

  • 資深大佬 : BadAngel

    NoSql 不就行了吗？想怎么来怎么来

  • 資深大佬 : 594duck

    @icerhe 老哥的回答非常好，有理有据。另外这个题主真的差，自己回贴竟然是十分钟了。

  • 資深大佬 : fyutou

    一个用户表+一个角色表，可行不

  • 資深大佬 : xy2020

    用户表的设计说简单也简单，说复杂也复杂，具体需要看业务需求：不仅要看现在的需求，还要看未来的需求。例如，如果当前的系统无论如何发展都不会和其它系统关联数据，或者用户在系统中只能有一个手机号、且历史手机号记录永远没有价值等等，这时我们就可以考虑用户用单表、且直接包含所有属性字段。但如果不是，例如系统必然会和其它产品数据连接，如 OA 系统一般都会和 HR 系统、财务系统、CRM 系统等等系统连接，或者用户可以有多个手机号记录，例如做业务回溯时必须对应办理业务时的手机号、或者是个充值系统等等，这时就必须用主表+属性表的形式。
    至于到底要不要做用户表合并，也是同样的思路：看业务需求，包括当前的和未来的。

  • 主 資深大佬 : Yuicon

    @594duck 你有问题吧 我顶个贴有什么关系 不然早沉下去了 而且虽然回复很多但是并没有我满意的答案 我的方案也是通用用户表加角色子表 只不过现在我想通过 json 类型把子表直接放在通用表里面 这样避免 crud 用户数据涉及到多个表

  • 主 資深大佬 : Yuicon

    @LokiSharp 我巴不得用户表大到索引很慢的程度 这样我工资就起飞了

  • 資深大佬 : wushigejiajia01

    @Yuicon 用 json 存有隐患的

    后期如果有需要做搜索或者筛选条件用到了 你说的“子表”信息字段，那就完蛋

    不要相信产品说的“以后不会用这些信息做查询筛选的”，

    我以前经历过，真的很痛苦

  • 主 資深大佬 : Yuicon

    @wushigejiajia01 这我调查过的 本来准备用 es 或者阿里云的 opensearch 解决 后来发现 mysql 本身就支持 可以正常查询的 而且效率还可以 我创建了 10w 条 查 json 里的某个字段 也只要 100ms 左右（辣鸡测试数据库）