做著做著就會發現這樣設計太過繁瑣，如果公司裡面所有員工都有這樣的許可權呢，每一個人都要配置？那是一件很痛苦的事情。因此再新增一個角色表，把某些人歸為一類，然後再把許可權分配給角色。角色屬下的使用者也就擁有了許可權。

使用者、角色之間的關係是一個使用者可以對應多個角色，一個角色可以對應多個使用者。多對多關係。

所以需要一箇中間表，相信大家都很熟悉，自然不會有疑問。

應用場景 

有了使用者和角色以後，就需要設計應用場景，比如一個應用程式有幾大模組（系統模組、專案管理模組、銷售模組），

類似這樣的模組就是一種應用場景，常見的還有 選單 、 操作 等等。

假設現在我們設計好了，應用場景包括 模組、選單、和操作，那麼應該有以下六種關係

1. 一個使用者可以對應多個模組，一個模組可以對應多個使用者。多對多關係。
2. 一個使用者可以對應多個選單，一個選單可以對應多個使用者。多對多關係。
3. 一個使用者可以對應多個操作，一個操作可以對應多個使用者。多對多關係。
4. 一個角色可以對應多個模組，一個模組可以對應多個角色。多對多關係。 
5. 一個角色可以對應多個選單，一個選單可以對應多個角色。多對多關係。  
6. 一個角色可以對應多個操作，一個操作可以對應多個角色。多對多關係。

於是建立六張表來維護這六種關係。

這樣設計看起來沒什麼問題。是的，如果沒有加入新的關係的話，這樣是已經可以滿足大部分的需求了。可是如果就是如果，新的關係（需求）往往會加入到系統進來。這個時候就需要再建立一個新的表。系統的複雜度也隨著增加。

可以看出，這樣的設計有幾個問題：

1. 資料表設計太複雜
2. 應對系統方案過於固定

三，把問題簡單化

 不同的應用場合，你可能會想出不同的需求，提了一個新的需求以後，可能會發現原來的設計沒方法實現了，於是還要新增一個新的表。這也是上面所提到的問題。 

 其實不必想得那麼複雜，許可權可以簡單描述為：

某某主體 在 某某領域 有 某某許可權 

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不僅僅只是使用和禁止兩種，包括分配許可權、授權許可權，都可以用這個欄位定義。只是這無疑加大了應用程式的設計難度，但是對於表設計可以不做出任何的修改就可以完成，可以看出其靈活性。