咱們在開發系統的時候，常常會遇到系統須要權限控制，而權限的控制程度不一樣有不一樣的設計方案。html
1. 基於角色的權限設計數據庫
這種方案是最多見也是比較簡單的方案，不過一般有這種設計已經夠了，因此微軟就設計出這種方案的通用作法，這種方案對於每個操做不作控制，只是在程序中根據角色對是否具備操做的權限進行控制；這裏咱們就不作詳述
post
2. 基於操做的權限設計spa
這種模式下每個操做都在數據庫中有記錄，用戶是否擁有該操做的權限也在數據庫中有記錄，結構以下：設計
可是若是直接使用上面的設計，會致使數據庫中的UserAction這張表數據量很是大，因此咱們須要進一步設計提升效率，請看方案33d
3. 基於角色和操做的權限設計orm
如上圖所示，咱們在添加了Role，和RoleAction表，這樣子就能夠減小UserAction中的記錄，而且使設計更靈活一點。htm
可是這種方案在用戶需求的考驗之下也可能顯得不夠靈活夠用，例如當用戶要求臨時給某位普通員工某操做權限時，咱們就須要新增長一種新的用戶角色，可是這種用戶角色是沒必要要的，由於它只是一種臨時的角色，若是添加一種角色還須要在收回此普通員工權限時刪除此角色，咱們須要設計一種更合適的結構來知足用戶對權限設置的要求。對象
4. 2,3組合的權限設計，其結構以下：blog
咱們能夠看到在上圖中添加了UserAction表，使用此表來添加特殊用戶的權限，改表中有一個字段HasPermission能夠決定用戶是否有某種操做的權限，改表中記錄的權限的優先級要高於UserRole中記錄的用戶權限。這樣在應用程序中咱們就須要經過UserRole和UserAction兩張表中的記錄判斷權限。
到這兒呢並不算完，有可能用戶還會給出這樣的需求：對於某一種action所操做的對象某一些記錄會有權限，而對於其餘的記錄沒有權限，好比說一個內容管理系統，對於某一些頻道某個用戶有修改的權限，而對於另一些頻道沒有修改的權限，這時候咱們須要設計更復雜的權限機制。
5. 對於同一種實體（資源）用戶能夠對一部分記錄有權限，而對於另一些記錄沒有權限的權限設計：
對於這樣的需求咱們就須要對每一種不一樣的資源建立一張權限表，在上圖中對Content和Channel兩種資源分別建立了UserActionContent和UserActionChannel表用來定義用戶對某條記錄是否有權限；這種設計是能夠知足用戶需求的可是不是很經濟，UserActionChannel和UserActionContent中的記錄會不少，而在實際的應用中並不是須要記錄全部的記錄的權限信息，有時候可能只是一種規則，好比說對於根Channel什麼級別的人有權限；這時候呢咱們就能夠定義些規則來判斷用戶權限，下面就是這種設計。
6. 涉及資源，權限和規則的權限設計
在這種設計下角色的概念已經沒有了，只須要Rule在程序中的類中定義用戶是否有操做某種對象的權限。
以上只是分析思路，若是有不對的地方，請你們指正。
來源：http://www.cnblogs.com/yukaizhao/archive/2007/04/15/user_role_action_permission.html