用戶和角色:通用權限管理系統數據庫表結構如何設計？

  一，前言 權限管理系統的應用者應該有三種不一樣性質上的使用，
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://club.sm160.com/showtopic-934193.aspx