本文關鍵詞：權限管理，由筆耕文化傳播整理發(fā)布。

通用權限管理設計 之 數(shù)據(jù)庫結(jié)構設計

一，前言 

權限管理系統(tǒng)的應用者應該有三種不同性質(zhì)上的使用，

A,使用權限

B,分配權限

C,授權權限 

本文只從《使用權限》和《分配權限》這兩種應用層面分析，暫時不考慮《授權權限》這種。

說到權限管理，首先應該想到，當然要設計一個用戶表，一個權限表。這樣就決定了一個人有什么樣的權限。

做著做著就會發(fā)現(xiàn)這樣設計太過繁瑣，如果公司里面所有員工都有這樣的權限呢，每一個人都要配置？那是一件很痛苦的事情。因此再添加一個角色表，把某些人歸為一類，然后再把權限分配給角色。角色屬下的用戶也就擁有了權限。

用戶、角色之間的關系是一個用戶可以對應多個角色，一個角色可以對應多個用戶。多對多關系。

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

有了用戶和角色以后，就需要設計應用場景，比如一個應用程序有幾大模塊（系統(tǒng)模塊、項目管理模塊、銷售模塊），

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

假設現(xiàn)在我們設計好了，應用場景包括 模塊、菜單、和操作，那么應該有以下六種關系

于是建立六張表來維護這六種關系。

這樣設計看起來沒什么問題。是的，如果沒有加入新的關系的話，這樣是已經(jīng)可以滿足大部分的需求了�？墒侨绻褪侨绻�，新的關系（需求）往往會加入到系統(tǒng)進來。這個時候就需要再建立一個新的表。系統(tǒng)的復雜度也隨著增加。

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

三，把問題簡單化

其實就是Who、What、How的問題

因此上面所提到的六張表其實可以設計一張表：

下面用一個例子做設計說明。“用戶、角色在頁面上的是使用權限”

詳細設計：

1，把菜單的配置放在數(shù)據(jù)庫上，每一個菜單對于一個唯一的編碼MenuNo，每一個“葉節(jié)點”的菜單項對于一個頁面(url)。

2，把按鈕的配置放在數(shù)據(jù)庫上，并歸屬于一個菜單項上（其實就是掛在某一個頁面上）。應該一個頁面可能會有幾個按鈕組，比如說有兩個列表，這兩個列表都需要有“增加、修改、刪除”。所以需要增加一個按鈕分組的字段來區(qū)分。

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"。

如果不清楚的可以看下圖：

 數(shù)據(jù)庫設計：

四，結(jié)語

說了這么多，其實我推薦的只是Privilege的表設計。這個表是who、what、how問題原型的設計。不僅擴展性、靈活性都很好，而且將復雜的權限管理系統(tǒng)濃縮成一句話。

 而PrivilegeOperation不僅僅只是使用和禁止兩種，包括分配權限、授權權限，都可以用這個字段定義。只是這無疑加大了應用程序的設計難度，但是對于表設計可以不做出任何的修改就可以完成，可以看出其靈活性。 

 posted on

  本文關鍵詞：權限管理，由筆耕文化傳播整理發(fā)布。