一张表还是两张表——大家一般怎么设计前台(app)用户和后台管理员的数据库与权限管理？

[varius]

RT 。 在做涉及到 ap/小程序 /前台用户的后台服务时，有两种方案。

1. 选择把用户和管理员放在一张表，通过角色来 RBAC 来区分。
2. 把用户和管理员作为不同类型，放在两张表。

#大家一般偏好哪种方案？

我的疑惑， 用 1 方案的时候，统一 JWT 鉴权，然后通过角色禁止登陆后台之类嘛? 用 2 方案的时候，会不会不好处理 JWT 之类的。

[Mitt]

如果要分表那么通常情况是前后台分离，不分表的话后台通常和前台同属一个前端项目，需要管理员去前台进行一些操作的，JWT 的话同理，不分离按 rbac 权限禁止登录，分离可以直接划分不同域名或 path 来区分

[liuxey]

看产品定位和需求，保不准哪天的需求是管理员也能登录“小程序”用某些功能

[newtype0092]

最好不要混在一起，外部用户表和后台用户表是两回事。
业务复杂以后可以引入独立的用户服务，外部用户库和后台用户库各自分配不同的 app_id，在用户服务中做统一的处理逻辑。

[varius]

@Mitt 这种大部分后台和前台都不是一个平台上的了，看来还是分表划算

[varius]

@liuxey 感觉老哥在暗示某些项目什么的哈哈哈哈

[varius]

@newtype0092 老哥稳妥！的确这是真正搞微服务的思路

[Mitt]

@varius 😅你对微服务的误解，这只是很普通的前后台，引入微服务只会增加复杂度不会降低耦合度，他俩本来就是耦合在一起的，分表好处是以后还可以再绑起来，只需要一个 via 表

[varius]

@Mitt 那其实是不是用 JHipster 里提倡的方案，抽象出一个 User，然后管理员一个表，用户一个表，然后用 User 来对应，这样比较好？

[Mitt]

@varius #8 这么说吧， 管理员用户对应后台，普通用户对应前台，这俩相互没有交集，如果产生交集，给管理员用户注册一个普通用户账号然后跟管理员用户绑定起来，如果不产生交集那么前后台用户都是独立的

[varius]

@Mitt THX 指点！

[hsluoyz]

后端用 casbin，前端用 casbin.js ，权限前后端联动

[varius]

@hsluoyz 这个一直听过，但是没使用过

[GDC]

@varius 就是他搞的 天天发帖吹 本来好好的项目 看多了也烦

[xuanbg]

一张表足矣。对于鉴权来说，可以对资源进行三个安全等级划分：
1 、公开，游客可访问
2 、私有，必须是注册用户且持有有效的 token
3 、授权，必须是注册用户且持有有效的 token，并获得授权

以上 3 个等级和用户有一毛钱关系吗？所以根本没有必要区分普通用户和管理员用户。人为区分两种用户，除了把系统复杂化，没有任何的好处。

[newtype0092]

@xuanbg #14 不同意你说的，这不是认为区分两种用户，而是两种用户正常情况本身就是无关的，强行耦合在一起才会有问题。
用户的查询逻辑一般都是关联用户的业务表的，这种查询大小是会随着用户量增长快速扩张的，后台账号则是关联另一套后台业务表，数据量可能小的多，如果耦合在一起，每次查询某一套业务的时候都要用条件过滤掉另一个类型的账号，这种额外开销是没有意义的。

[newtype0092]

#8 开始时两张表够用，中期通用的逻辑慢慢便多了，再抽出一个和身份无关的通用 User 表，对同一个实际用户的不同身份做关联，再往大做，你的前后两个系统规模都很大了，要做拆分的时候，User 表也就该拆成独立的服务了。

用户放不放在一个表里，最根本还是看怎么用，比如教育类的 app，老师和学生完全是两个身份，所有查询基本都不通用，那放一个表里就很难受，前端用户和后台用户一般也是这个情况，除非是类似 QQ 空间这种，空间编辑后台本身也是用户功能的一部分，这种就不需要拆分。

[xuanbg]

@newtype0092 没明白为啥要“用条件过滤掉另一个类型的账号”？

[varius]

@GDC 哈哈哈哈，原来如此~

[varius]

@xuanbg JHipster 的 concept 是这种意思

[varius]

@newtype0092 明白，谢谢老哥经验之谈