请稍等 ...
×

采纳答案成功!

向帮助你的同学说点啥吧!感谢那些助人为乐的人

我有个角色roles和菜单menus关联关系的问题

老师这里将的权限是角色和菜单关联,菜单中具备操作权限。那如果有两个不同的角色,拥有相同的菜单,但是却需要不同的操作权限,那按照现在课程这样进行表划分貌似无法实现啊。这种情况下实体应该怎么建立关联呢?

正在回答 回答被采纳积分+3

2回答

Brian 2023-08-11 10:47:35

https://img1.sycdn.imooc.com//szimg/64d5a1310956554d23281582.jpg

一图胜千言。


如果按照现在课程讲的继续扩展,实体的关联关系就是 roles 多对多关联 权限表,权限表 多对一关联 菜单表。这样的话角色和菜单表是没有直接关系的。如果我只想单纯查询这个角色的菜单,那么就需要关联查询权限表,然后菜单去重。
——你的理解是对的


但是我更倾向另一种办法实现,roles 多对多关联菜单表,roles 一对多关联权限表,菜单表只有菜单(唯一),前端页面操作的时候,我们会为角色选择菜单,菜单id和权限字符串插入到权限表
——这里其实就是菜单与权限的多对多的关系

那是因为权限表的每条数据不应该是和多个角色共享的
——权限表,在目前的情况下,是一个权限关系表,或者叫权限记录表,实体表与关系表合二为一了,给你这种感觉。如果是实体一张表,关系表是一张表,就可以共用实体表,与你上面的菜单id是唯一的是一回事

0 回复 有任何疑惑可以回复我~
  • 我的做法:
      操作权限与菜单权限在一张表存储,用type标记权限类型。用parentId标记及联关系,这样其实也是可以满足需求的。接下来其实就是做好api数据权限的维护了。
    回复 有任何疑惑可以回复我~ 2023-08-14 17:08:29
  • 那也OK
    回复 有任何疑惑可以回复我~ 2023-08-16 18:22:30
Brian 2023-08-09 11:56:02

非常好的问题。

那如果有两个不同的角色,拥有相同的菜单,但是却需要不同的操作权限——这句来到现实的业务中,

一般是不是:

1. 分读的权限,有的人只能看;

2. 分读与增,有的人即能读也能增,不能写与改;

3. 分读与改,有的人只能读与改,不能增,不能删;

4. 有的人,有管理权限,能读写增改;

...

那么这种情况,你就需要至少4种角色,每种角色对应上面的一种操作权限。

给该用户进行分配的时候,即把上面的权限分配该用户。


同时,一般情况下,菜单权限与操作权限(数据权限)与课程中不一样,在现实中,一般会分开存在两张表中,这样就可以针对不同的人,同一个菜单可读,却不同的写权限设置了。

0 回复 有任何疑惑可以回复我~
  • 提问者 城北丶 #1
    如果按照现在课程讲的继续扩展,实体的关联关系就是 roles 多对多关联 权限表,权限表 多对一关联 菜单表。这样的话角色和菜单表是没有直接关系的。如果我只想单纯查询这个角色的菜单,那么就需要关联查询权限表,然后菜单去重。
    但是我更倾向另一种办法实现,roles 多对多关联菜单表,roles 一对多关联权限表,菜单表只有菜单(唯一),前端页面操作的时候,我们会为角色选择菜单,然后为这个角色的每个菜单选择操作权限,这样就可以把菜单id和权限字符串插入到权限表。我们在查询角色的时候,会关联查询出菜单表和权限表。至于角色和权限是一对多关系,那是因为权限表的每条数据不应该是和多个角色共享的,因为这样在更新的时候逻辑上其实有问题。比如我们只想为角色1更新权限,但是这个权限还关联其他的角色,其实是不对的。
    我不知道我这样做是否还有问题,因为现在正在开发一个项目,我需要做项目的前后端,我认为这样做,不管是前端根据用户生成路由和操作按钮还是后端查询应该都是最优的。
    回复 有任何疑惑可以回复我~ 2023-08-09 17:07:40
问题已解决,确定采纳
还有疑问,暂不采纳
意见反馈 帮助中心 APP下载
官方微信