一张表还是两张表——大家一般怎么设计前台(app)用户和后台管理员的数据库与权限管理？
varius · 2021-02-09 19:38:40 +08:00 · 4128 次点击这是一个创建于 1386 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT 。 在做涉及到 ap/小程序 /前台用户的后台服务时，有两种方案。
- 选择把用户和管理员放在一张表，通过角色来 RBAC 来区分。
- 把用户和管理员作为不同类型，放在两张表。
#大家一般偏好哪种方案？
我的疑惑， 用 1 方案的时候，统一 JWT 鉴权，然后通过角色禁止登陆后台之类嘛? 用 2 方案的时候，会不会不好处理 JWT 之类的。
 |
1
Mitt 2021-02-09 19:47:03 +08:00 via iPhone
如果要分表那么通常情况是前后台分离，不分表的话后台通常和前台同属一个前端项目，需要管理员去前台进行一些操作的，JWT 的话同理，不分离按 rbac 权限禁止登录，分离可以直接划分不同域名或 path 来区分
|
 |
2
liuxey 2021-02-09 19:51:04 +08:00
看产品定位和需求，保不准哪天的需求是管理员也能登录“小程序”用某些功能
 |
 |
3
newtype0092 2021-02-09 20:07:09 +08:00
最好不要混在一起，外部用户表和后台用户表是两回事。
业务复杂以后可以引入独立的用户服务，外部用户库和后台用户库各自分配不同的 app_id，在用户服务中做统一的处理逻辑。 |
 |
6
varius OP @newtype0092 老哥稳妥！的确这是真正搞微服务的思路
|
|
7
Mitt 2021-02-09 20:19:00 +08:00 via iPhone
@varius 😅你对微服务的误解，这只是很普通的前后台，引入微服务只会增加复杂度不会降低耦合度，他俩本来就是耦合在一起的，分表好处是以后还可以再绑起来，只需要一个 via 表
|
|
8
varius OP @Mitt 那其实是不是用 JHipster 里提倡的方案，抽象出一个 User，然后管理员一个表，用户一个表，然后用 User 来对应，这样比较好？
|
|
9
Mitt 2021-02-09 21:04:22 +08:00
@varius #8 这么说吧， 管理员用户对应后台，普通用户对应前台，这俩相互没有交集，如果产生交集，给管理员用户注册一个普通用户账号然后跟管理员用户绑定起来，如果不产生交集那么前后台用户都是独立的
|
 |
11
hsluoyz 2021-02-09 21:42:05 +08:00
后端用 casbin，前端用 casbin.js ，权限前后端联动
|
 |
14
xuanbg 2021-02-10 08:52:58 +08:00
一张表足矣。对于鉴权来说，可以对资源进行三个安全等级划分：
1 、公开，游客可访问 2 、私有，必须是注册用户且持有有效的 token 3 、授权，必须是注册用户且持有有效的 token，并获得授权 以上 3 个等级和用户有一毛钱关系吗？所以根本没有必要区分普通用户和管理员用户。人为区分两种用户，除了把系统复杂化，没有任何的好处。 |
|
15
newtype0092 2021-02-10 10:01:02 +08:00
@xuanbg #14 不同意你说的，这不是认为区分两种用户，而是两种用户正常情况本身就是无关的，强行耦合在一起才会有问题。
用户的查询逻辑一般都是关联用户的业务表的，这种查询大小是会随着用户量增长快速扩张的，后台账号则是关联另一套后台业务表，数据量可能小的多，如果耦合在一起，每次查询某一套业务的时候都要用条件过滤掉另一个类型的账号，这种额外开销是没有意义的。 |
|
16
newtype0092 2021-02-10 10:11:34 +08:00
#8 开始时两张表够用，中期通用的逻辑慢慢便多了，再抽出一个和身份无关的通用 User 表，对同一个实际用户的不同身份做关联，再往大做，你的前后两个系统规模都很大了，要做拆分的时候，User 表也就该拆成独立的服务了。
用户放不放在一个表里，最根本还是看怎么用，比如教育类的 app，老师和学生完全是两个身份，所有查询基本都不通用，那放一个表里就很难受，前端用户和后台用户一般也是这个情况，除非是类似 QQ 空间这种，空间编辑后台本身也是用户功能的一部分，这种就不需要拆分。 |
|
17
xuanbg 2021-02-10 20:07:54 +08:00
@newtype0092 没明白为啥要“用条件过滤掉另一个类型的账号”？
|
|
20
varius OP @newtype0092 明白，谢谢老哥经验之谈
|
Select Language