一，前言
權限管理系統的應用者應該有三種不同性質上的使用，
A,使用權限
B,分配權限
C,授權權限
本文只從《使用權限》和《分配權限》這兩種應用層面分析，暫時不考慮《授權權限》這種。
二，初步分析
用戶和角色
說到權限管理，首先應該想到，當然要設計一個用戶表，一個權限表。這樣就決定了一個人有什麼樣的權限。
做着做着就會發現這樣設計太過繁瑣，如果公司裏面所有員工都有這樣的權限呢，每一個人都要配置？那是一件很痛苦的事情。因此再添加一個角色表，把某些人歸爲一類，然後再把權限分配給角色。角色屬下的用戶也就擁有了權限。
用戶、角色之間的關係是一個用戶可以對應多個角色，一個角色可以對應多個用戶。多對多關係。
所以需要一箇中間表，相信大家都很熟悉，自然不會有疑問。
應用場景
有了用戶和角色以後，就需要設計應用場景，比如一個應用程序有幾大模塊（系統模塊、項目管理模塊、銷售模塊），
類似這樣的模塊就是一種應用場景，常見的還有 菜單 、 操作 等等。
假設現在我們設計好了，應用場景包括 模塊、菜單、和操作，那麼應該有以下六種關係
- 一個用戶可以對應多個模塊，一個模塊可以對應多個用戶。多對多關係。
- 一個用戶可以對應多個菜單，一個菜單可以對應多個用戶。多對多關係。
- 一個用戶可以對應多個操作，一個操作可以對應多個用戶。多對多關係。
- 一個角色可以對應多個模塊，一個模塊可以對應多個角色。多對多關係。
- 一個角色可以對應多個菜單，一個菜單可以對應多個角色。多對多關係。
- 一個角色可以對應多個操作，一個操作可以對應多個角色。多對多關係。
於是建立六張表來維護這六種關係。
這樣設計看起來沒什麼問題。是的，如果沒有加入新的關係的話，這樣是已經可以滿足大部分的需求了。可是如果就是如果，新的關係（需求）往往會加入到系統進來。這個時候就需要再建立一個新的表。系統的複雜度也隨着增加。
可以看出，這樣的設計有幾個問題：
- 數據表設計太複雜
- 應對系統方案過於固定
三，把問題簡單化
不同的應用場合，你可能會想出不同的需求，提了一個新的需求以後，可能會發現原來的設計沒方法實現了，於是還要添加一個新的表。這也是上面所提到的問題。
其實不必想得那麼複雜，權限可以簡單描述爲：
某某主體 在 某某領域 有 某某權限
1，主體可以是用戶，可以是角色，也可以是一個部門
2， 領域可以是一個模塊，可以是一個頁面，也可以是頁面上的按鈕
3， 權限可以是“可見”，可以是“只讀”，也可以是“可用”(如按鈕可以點擊)
其實就是Who、What、How的問題
因此上面所提到的六張表其實可以設計一張表：
四，實例說明
下面用一個例子做設計說明。“用戶、角色在頁面上的是使用權限”
詳細設計：
1，把菜單的配置放在數據庫上，每一個菜單對於一個唯一的編碼MenuNo，每一個“葉節點”的菜單項對於一個頁面(url)。
2，把按鈕的配置放在數據庫上，並歸屬於一個菜單項上（其實就是掛在某一個頁面上）。應該一個頁面可能會有幾個按鈕組，比如說有兩個列表，這兩個列表都需要有“增加、修改、刪除”。所以需要增加一個按鈕分組的字段來區分。
3,把菜單權限分配給用戶/角色，PrivilegeMaster爲"User"或"Role",PrivilegeMasterValue爲UserID或RoleID,PrivilegeAccess爲“Menu",PrivilegeAccessValue爲MenuNo,PrivilegeOperation爲"enabled"
4,把按鈕權限分配給用戶/角色，PrivilegeMaster爲"User"或"Role",PrivilegeMasterValue爲UserID或RoleID,PrivilegeAccess爲“Button",PrivilegeAccessValue爲BtnID,PrivilegeOperation爲"enabled"
5,如果需要禁止單個用戶的權限，PrivilegeOperation 設置爲"disabled"。
如果不清楚的可以看下圖：
數據庫設計：
四，結語
說了這麼多，其實我推薦的只是Privilege的表設計。這個表是who、what、how問題原型的設計。不僅擴展性、靈活性都很好，而且將複雜的權限管理系統濃縮成一句話。
而PrivilegeOperation不僅僅只是使用和禁止兩種，包括分配權限、授權權限，都可以用這個字段定義。只是這無疑加大了應用程序的設計難度，但是對於表設計可以不做出任何的修改就可以完成，可以看出其靈活性。
本文轉自：http://www.cnblogs.com/leoxie2011/archive/2011/05/19/2050626.html