方案没有合不合适。业务场景决定了你使用什么样的技术范畴。
一般将角色作为权限的集合、然后角色赋予账号 是很普遍的做法。这种方案适合角色可共享多账户。
比如：包含 增删改查 角色。直接赋给一批人。大家都能用。如果要去除“删”。直接操作一次角色就好了

权限直接与账号关联。会导致每个人都要将权限操作一遍。
比如：多人有 增删改查 权限。你想要取消他们的“删” 权限。那么你要把这些人都操作一遍。

可以使用ACL（基于用户权限控制），
我们常用的是RBAC（基于角色权限控制），

但是ACL的设计模式有：
(1)用户和权限的关系比较臃肿
(2)不易于扩展和维护

不合适，账号直接关联权限，扩展性肯定没有角色关联权限高
就像你写接口，不依赖与具体服务，依赖于上层接口，角色就类似于上层接口，你增加权限就只需要修改角色，而不用
具体修改每个账号

角色-资源关联表

资源包括菜单

说说我之前在一家公司做的权限模块设计吧。 大致上是这样一种关系： 用户->角色->资源 。 先说一下"资源"的定义，我理解的“资源”就是对某个指定接口的访问权限。例如有一个登陆接口，只有A角色才运行登陆，因此是通过用户的唯一标识去查用户属于的一个或多个角色，再将角色所用的权限返回。 转换一下思路，其实"角色"就是一部分权限接口的"集合"。而题主你所谓的"关联菜单"其实包含了两种不同的“权限”：可视权限、访问权限；
可视权限是某些东西只有特定角色能"看"，但是能看到不代表能执行，所以可视权限和访问权限应该分开，这里粒度够细才能实现各种业务需要的横向扩展。
你可以让用户直接关联菜单，把"角色"这一层级去掉后，只是在维护和管理上不方便，本质是没变的。

我们公司设计的权限不但可以设置在角色上，也可以设置在用户上，这是一个继承的关系。
如有一个角色：客服，有二个用户A，B都是客服角色，这时候A，B都有了 客服的所有功能。
这时候还可以单独设置A有比B更多的功 能。这时候是合并的关系
当然也可以设置A比B更少的功能，就在用户A禁用从客服继承过来的功能。。

看你的业务需不需要区分的那么详细了

主要看你的业务是不是需要，需要的话是可以实现的；