使用者和角色:通用許可權管理系統資料庫表結構如何設計？
阿新 • • 發佈：2019-01-09
一，前言 許可權管理系統的應用者應該有三種不同性質上的使用，
A,使用許可權
B,分配許可權
C,授權許可權
本文只從《使用許可權》和《分配許可權》這兩種應用層面分析，暫時不考慮《授權許可權》這種。
二，初步分析使用者和角色 說到許可權管理，首先應該想到，當然要設計一個使用者表，一個許可權表。這樣就決定了一個人有什麼樣的許可權。
做著做著就會發現這樣設計太過繁瑣，如果公司裡面所有員工都有這樣的許可權呢，每一個人都要配置？那是一件很痛苦的事情。因此再新增一個角色表，把某些人歸為一類，然後再把許可權分配給角色。角色屬下的使用者也就擁有了許可權。
使用者、角色之間的關係是一個使用者可以對應多個角色，一個角色可以對應多個使用者。多對多關係。
所以需要一箇中間表，相信大家都很熟悉，自然不會有疑問。
應用場景 有了使用者和角色以後，就需要設計應用場景，比如一個應用程式有幾大模組（系統模組、專案管理模組、銷售模組），
類似這樣的模組就是一種應用場景，常見的還有 選單 、 操作 等等。
假設現在我們設計好了，應用場景包括 模組、選單、和操作，那麼應該有以下六種關係
於是建立六張表來維護這六種關係。
這樣設計看起來沒什麼問題。是的，如果沒有加入新的關係的話，這樣是已經可以滿足大部分的需求了。可是如果就是如果，新的關係（需求）往往會加入到系統進來。這個時候就需要再建立一個新的表。系統的複雜度也隨著增加。
可以看出，這樣的設計有幾個問題：
不同的應用場合，你可能會想出不同的需求，提了一個新的需求以後，可能會發現原來的設計沒方法實現了，於是還要新增一個新的表。這也是上面所提到的問題。
其實不必想得那麼複雜，許可權可以簡單描述為：
某某主體 在 某某領域 有 某某許可權
因此上面所提到的六張表其實可以設計一張表：
四，例項說明
下面用一個例子做設計說明。“使用者、角色在頁面上的是使用許可權”
詳細設計：
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問題原型的設計。不僅擴充套件性、靈活性都很好，而且將複雜的許可權管理系統濃縮成一句話。
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不僅僅只是使用和禁止兩種，包括分配許可權、授權許可權，都可以用這個欄位定義。只是這無疑加大了應用程式的設計難度，但是對於表設計可以不做出任何的修改就可以完成，可以看出其靈活性。