一，前言

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

A,使用權(quán)限

B,分配權(quán)限

C,授權(quán)權(quán)限

本文只從《使用權(quán)限》和《分配權(quán)限》這兩種應(yīng)用層面分析，暫時不考慮《授權(quán)權(quán)限》這種。

二，初步分析

用戶和角色

說到權(quán)限管理，首先應(yīng)該想到，當(dāng)然要設(shè)計一個用戶表，一個權(quán)限表。這樣就決定了一個人有什么樣的權(quán)限。

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

用戶、角色之間的關(guān)系是一個用戶可以對應(yīng)多個角色，一個角色可以對應(yīng)多個用戶。多對多關(guān)系。

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

應(yīng)用場景

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

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

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

一個用戶可以對應(yīng)多個模塊，一個模塊可以對應(yīng)多個用戶。多對多關(guān)系。

一個用戶可以對應(yīng)多個菜單，一個菜單可以對應(yīng)多個用戶。多對多關(guān)系。

一個用戶可以對應(yīng)多個操作，一個操作可以對應(yīng)多個用戶。多對多關(guān)系。

一個角色可以對應(yīng)多個模塊，一個模塊可以對應(yīng)多個角色。多對多關(guān)系。

一個角色可以對應(yīng)多個菜單，一個菜單可以對應(yīng)多個角色。多對多關(guān)系。

一個角色可以對應(yīng)多個操作，一個操作可以對應(yīng)多個角色。多對多關(guān)系。

于是建立六張表來維護(hù)這六種關(guān)系。

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

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

數(shù)據(jù)表設(shè)計太復(fù)雜

應(yīng)對系統(tǒng)方案過于固定

三，把問題簡單化

不同的應(yīng)用場合，你可能會想出不同的需求，提了一個新的需求以后，可能會發(fā)現(xiàn)原來的設(shè)計沒方法實現(xiàn)了，于是還要添加一個新的表。這也是上面所提到的問題。

其實不必想得那么復(fù)雜，權(quán)限可以簡單描述為：

某某主體 在 某某領(lǐng)域 有 某某權(quán)限

1. 主體可以是用戶，可以是角色，也可以是一個部門
2. 領(lǐng)域可以是一個模塊，可以是一個頁面，也可以是頁面上的按鈕
3. 權(quán)限可以是“可見”，可以是“只讀”，也可以是“可用”(如按鈕可以點擊)

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

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

四，實例說明

下面用一個例子做設(shè)計說明。“用戶、角色在頁面上的是使用權(quán)限”

詳細(xì)設(shè)計：

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

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

3,把菜單權(quán)限分配給用戶/角色，PrivilegeMaster為"User"或"Role",PrivilegeMasterValue為UserID或RoleID,PrivilegeAccess為“Menu",PrivilegeAccessValue為MenuNo,PrivilegeOperation為"enabled"

4,把按鈕權(quán)限分配給用戶/角色，PrivilegeMaster為"User"或"Role",PrivilegeMasterValue為UserID或RoleID,PrivilegeAccess為“Button",PrivilegeAccessValue為BtnID,PrivilegeOperation為"enabled"

5,如果需要禁止單個用戶的權(quán)限，PrivilegeOperation 設(shè)置為"disabled"。

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

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

五，結(jié)語

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

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

原文鏈接：http://www.cnblogs.com/leoxie2011/archive/2011/05/19/2050626.html

【編者推薦】

1. 思科推新數(shù)據(jù)中心解決方案支持SQL Server
2. PostgreSQL的.NET驅(qū)動程序Npgsql中參數(shù)對象的一個Bug
3. SQL Server表最小行的一個糾結(jié)問題
4. 云端數(shù)據(jù)庫:微軟SQL Azure及其應(yīng)用場景
5. SQL點滴之收集SQL Server線程等待信息