这是一个创建于 1970 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如一个后台有公司自己的管理员、运维等等 又有商户用户 商户的员工之类的
我在好几家公司看到都是不同身份单独建表 后面写业务痛苦万分 比如登录、权限
我后面想改成用统一的用户表 又有不同身份的用户需要的字段不一样的问题 之前我是不删原来的身份表来当子表存放特殊字段 但是有同步数据的麻烦
现在换了家公司 遇到同样的问题 现在我的方案是统一用户表 增加一个 json 字段来存放身份自定义字段 这样就有搜索问题 准备用 es 这类来解决
不知道大家有没有刚好的方案
 | 1 Yuicon OP 10 分钟了 大佬们 |
 | 2 TORYOI 2020-05-26 16:35:45 +08:00  2 |
 | 3 AngryMagikarp 2020-05-26 16:36:13 +08:00 基本用户表中加入一个身份字段，比如 role，然后针对每一种 role 创建一个信息表。 用 JSON 来存不方便查询、更新等操作。 |
 | 4 yinzhili 2020-05-26 16:36:21 +08:00 主表+扩展表 这样的做法比较常见 |
 | 5 sagaxu 2020-05-26 16:46:47 +08:00 via Android 不要统一 不要统一 不要统一 |
 | 7 donnior 2020-05-26 17:05:38 +08:00 keycloak 之类的方案能满足你的需求不？ |
 | 9 fighterlyt 2020-05-26 17:24:13 +08:00 @Yuicon 不要混淆了业务复杂度和技术复杂度，技术人员能够调整或者掌控的只有技术复杂度。不同层次的问题，需要在不同层次上解决。用户的登录问题或者说权限问题，引入专门的策略引擎，就可以解决这个问题了，推荐 OPA. |
| 10 Yuicon OP @fighterlyt 我觉得这部分是可以通用的 微服务化后 一个统一的用户表是刚需 |
| 11 fighterlyt 2020-05-26 17:32:44 +08:00 @Yuicon 无论如何,内聚不是体现在表上的，而是服务,数据只是载体，服务才是业务 |
 | 12 janwarlen 2020-05-26 17:34:50 +08:00 好文 |
 | 13 wushigejiajia01 2020-05-26 17:39:43 +08:00 via Android 这不就是用 基本信息表 + 扩展信息表 两张表就可以了啊 用户姓名、id 、身份类型之类放基础信息表，各个身份独有信息放扩展表 缺陷就是有多个身份就会存在多个扩展表 |
 | 14 chendy 2020-05-26 17:41:20 +08:00 用户基本信息统一，不同业务不同权限在各自的数据里做 |
 | 15 xuanbg 2020-05-26 17:43:10 +08:00 不同身份仅仅是不同应用的不同角色而已，只要角色表加一个 appId 字段就行了。https://github.com/xuanbg/insight_auth 这个项目的表结构楼主可以参考一下 |
 | 16 icerhe 2020-05-26 17:52:11 +08:00 就你描述的业务而言.运营公司内部的员工(管理,运维等)和外部商户的员工(库管,业务员)就不是一类业务不是一类对象, 本来就不该统一,更不该放在一张表里. 如果你发现不同的用户很难统一很难通用, 那么很可能他们就不能统一不该通用. 退一万步讲, 就算未来有一天你发现两种用户可以统一, 把分离的用户表和业务代码合并所需的重构工作量,也远小于把原来合并的用户表和代码拆开的工作量, 咱们码农要了解业务, 根据业务现实而不是一些死板的"设计原则"来设计系统, 业务现实是第一位的, 应该是设计原则帮助我们更好的实现业务而不是反过来让业务适应设计原则, 那是削足适履 |
| 17 icerhe 2020-05-26 17:53:54 +08:00 如果权限是全站统一的, 那么权限可以一张表里统一管理, 如果用户本身就不同类,那么就不要强行把用户塞在一起.用户表分离,权限统一管理即可 |
 | 18 keepeye 2020-05-26 17:59:36 +08:00 用户可以统一，但不是把所有业务的用户资料都往一个表里面塞。可以参考下 ucenter |
 | 19 magygt 2020-05-26 18:02:14 +08:00 2 这大概是大厂都在建中台的原因吧。 具体一点，一张表的方案，初期可能是技术友好，实现起来快。多张表的方案，业务友好，边界清晰，初期复杂度高，但后期拓展性更好。 而中台抽象共性，具体解决特性。可以理解成对业务方是一张表。 |
 | 20 bsg1992 2020-05-26 18:02:51 +08:00 业务不一样 不需要统一 |
 | 21 GG668v26Fd55CP5W 2020-05-26 18:08:18 +08:00 via iPhone @wushigejiajia01 没错，WordPress 就是这样实现的，一张 user 表，一个 user_meta 表。理论上可以无限扩展，缺点就是经常要关联查询 |
 | 22 tuochenlyu 2020-05-26 21:29:01 +08:00 via iPhone 建议业务不明确或变化快时，能不拆就不拆，通过附属表的一个一段区分业务类型，数据库字段名称用 string1,int1 之类的代替，再用 orm 映射成有意义的名称。这样多个附属表就合并成了一个表。 后面业务量大或者业务稳定明确，再拆分也不迟。 |
 | 23 janxin 2020-05-26 21:38:10 +08:00 只有用户身份标识统一，其他的无需统一 |
 | 24 zxcslove 2020-05-26 21:56:54 +08:00 人员，身份，等级，部门，这些可以认真模仿一下现实世界。 |
 | 25 night98 2020-05-26 22:08:58 +08:00 是这样的，如果你的业务需求是单个用户账号可能存在多个角色时，那么放在一张表是比较合适的场景，比如一个商户账号既是商户，又是运维。这种情况下就比较适合单表存储，另外开设角色表和角色对应的权限表。 而如果你的业务需求是各个角色涉及的业务操作完全不一样，那么直接开多个表即可，将不同用户账户的服务完全隔离开，比如商户方单独有商户的服务，用户单独用户的服务，运维单独运维的服务，这样既减少了鉴权的请求，同时也更容易理解数据的边界。 |
 | 26 saulshao 2020-05-26 22:14:18 +08:00 建立一个基础的用户表，这个表只存放所有角色都需要用到的字段，例如名字，密码，电子邮件，手机号...... 其余的字段按照不同的角色划分，例如供应商表存放发货地址，收款账号，等等。 我之前也一直觉得，扩展性的意思是见了一个表用一辈子，有业务需求的时候不改最佳。 但是这个世界是变化的，扩展性最佳的例子，其实是建立起一个额外的表，然后对应的 CRUD 。 |
 | 27 akira 2020-05-26 22:30:44 +08:00 维护系统的人 和 使用系统的人，这 2 类账号最好还是分离 |
 | 28 jones2000 2020-05-26 23:31:06 +08:00 用 mongo， 扩展也方便。 |
 | 29 jugelizi 2020-05-26 23:41:49 +08:00 via iPhone 这是到处挖坑啊 |
 | 30 LokiSharp 2020-05-27 00:53:20 +08:00 via Android 单个表大了索引会很慢的 |
 | 31 xy90321 2020-05-27 01:11:48 +08:00 强行统一意义何在 在你觉得都是用户（因为最终是对应具体的物理人？？？），可是换个角度看根本就不是不同 entity |
 | 32 BadAngel 2020-05-27 07:02:31 +08:00 via Android NoSql 不就行了吗？想怎么来怎么来 |
 | 34 fyutou 2020-05-27 09:32:50 +08:00 一个用户表+一个角色表，可行不 |
 | 35 xy2020 2020-05-27 09:52:39 +08:00 via Android 用户表的设计说简单也简单，说复杂也复杂，具体需要看业务需求：不仅要看现在的需求，还要看未来的需求。例如，如果当前的系统无论如何发展都不会和其它系统关联数据，或者用户在系统中只能有一个手机号、且历史手机号记录永远没有价值等等，这时我们就可以考虑用户用单表、且直接包含所有属性字段。但如果不是，例如系统必然会和其它产品数据连接，如 OA 系统一般都会和 HR 系统、财务系统、CRM 系统等等系统连接，或者用户可以有多个手机号记录，例如做业务回溯时必须对应办理业务时的手机号、或者是个充值系统等等，这时就必须用主表+属性表的形式。 至于到底要不要做用户表合并，也是同样的思路：看业务需求，包括当前的和未来的。 |
| 36 Yuicon OP @594duck 你有问题吧 我顶个贴有什么关系 不然早沉下去了 而且虽然回复很多但是并没有我满意的答案 我的方案也是通用用户表加角色子表 只不过现在我想通过 json 类型把子表直接放在通用表里面 这样避免 crud 用户数据涉及到多个表 |
| 38 wushigejiajia01 2020-05-27 13:34:43 +08:00 |
| 39 Yuicon OP @wushigejiajia01 这我调查过的 本来准备用 es 或者阿里云的 opensearch 解决 后来发现 mysql 本身就支持 可以正常查询的 而且效率还可以 我创建了 10w 条 查 json 里的某个字段 也只要 100ms 左右（辣鸡测试数据库） |
Select Language