rbac用户权限控制的疑问？

Question

我看了下面这篇文章： RBAC用户角色权限设计方案

其中有这么一幅图：

我对菜单表和功能操作表的界定不是太清楚，比如一个系统中有下面几个菜单：

1. 用户管理（包括添加用户、查询用户、删除用户等几个菜单）
2. 文章管理（包括添加文章、查询文章、删除文章等几个菜单）

那么，这里的添加用户、查询用户、删除用户等几个子菜单与功能操作中的添加用户、查询用户、删除用户有什么区别，如果没有区别，那么功能操作表就不需要单独弄出来了？请问下应该如何界定两者的区别，什么时候属于菜单，什么时候属于功能？

Answer 1

感谢邀请……不过……哎哟我去，好晕啊！！

这个数据库结构当然是为Web应用设计的。所以从Web应用的角度来理解这个问题就很容易了。

菜单在Web应用中一般叫导航条。导航条本身是位于前端的视觉元素，其本身并不具备操作后端的功能。点击导航条的项目，和点击链接的行为是一样的，通过访问URL来与后台建立联系。（菜单表中有一个“菜单URL”，这个就表示菜单点击时要命令浏览器访问哪里）

而功能操作在Web应用中的意思就是，控制用户访问的URL如何解析，在PHP等服务器端程序中该对应到哪里。功能操作只关心URL本身，而并不关心是谁在访问，从哪访问。无论是点击菜单或网页中的链接，还是直接输入地址，甚至通过cURL等工具进行请求，对功能操作而言都没有区别。（功能操作表中有一个“拦截URL前缀”，这个就是一个简单的URL解析系统，控制不同的URL交给不同的后台程序处理）

这就说明了为什么同一件事要在菜单和操作中出现两次了：一个是前端(HTML/CSS/JS等)，一个是后端(PHP/JSP/Python WSGI等)。前后端配合才能做出事情。

如果按照MVC架构来解释，可以说的非常简洁：在这个结构里，菜单是V（视图）层，操作是C（控制）层。两层间的协调完成一个完整的动作。

在这个系统中，前后端的权限控制是分开的。可以单独控制前端菜单不显示，或后端程序不执行。这也就是说稍有不慎，就会做出两件很诡异的事情：

• 菜单中没有某动作，但只要知道该动作的URL，直接输入之就能成功执行。
• 菜单中明明有某动作，但点击之后被后台程序通知没有权限，拒绝执行。

---

这个权限控制系统相当的庞杂。MVC加上存储(S)四个层中，几乎所有的行为都被权限约束。而用户不光可以属于某种角色，还可以为特定用户在角色之外，授予单独的权限。并且关系图中所有的关系都存在个中间表格，即所有关系都是多对多的。这个系统的“高大全”确实很大程度上超出了我的想象。我估计99%的程序都没有必要把权限系统做成这个样子。

如此的架构必然是在一个明确的需求下，通过长期的、渐进性的实践而逐步达到的。所以我想特别提醒一下：“学里子，不要学架子”。要理解别人扩展出复杂系统的过程，而不要死背别人灵活创造出来的结果。

最忌讳的是生搬硬套，把别人渐进增强的成果，一口气全都实现出来。这样就彻底违反了Knuth提出的“过早优化是万恶之源”这个原则，给自己的程序从开发伊始，就引入一大堆难以收拾的麻烦。这最终会绝对会让项目的开发无法收场的。

Answer 2

添加删除是行为，是动作，怎么能作为子菜单，关于功能操作，在你实际表中是存储什么没表述清楚