web權限系統之功能權限

轉載地址:http://www.cnblogs.com/leoxie2011/archive/2011/05/19/2050626.html html

通用權限管理設計 之 數據庫結構設計數據庫

一,前言 

權限管理系統的應用者應該有三種不一樣性質上的使用,數據庫設計

A,使用權限編碼

B,分配權限url

C,受權權限 spa

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

二,初步分析

用戶和角色 

說到權限管理,首先應該想到,固然要設計一個用戶表,一個權限表。這樣就決定了一我的有什麼樣的權限。htm

作着作着就會發現這樣設計太過繁瑣,若是公司裏面全部員工都有這樣的權限呢,每個人都要配置?那是一件很痛苦的事情。所以再添加一個角色表,把某些人歸爲一類,而後再把權限分配給角色。角色屬下的用戶也就擁有了權限。blog

用戶、角色之間的關係是一個用戶能夠對應多個角色,一個角色能夠對應多個用戶。多對多關係。項目管理

因此須要一箇中間表,相信你們都很熟悉,天然不會有疑問。

應用場景 

有了用戶和角色之後,就須要設計應用場景,好比一個應用程序有幾大模塊(系統模塊、項目管理模塊、銷售模塊),

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

假設如今咱們設計好了,應用場景包括 模塊、菜單、和操做,那麼應該有如下六種關係

  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不單單只是使用和禁止兩種,包括分配權限、受權權限,均可以用這個字段定義。只是這無疑加大了應用程序的設計難度,可是對於表設計能夠不作出任何的修改就能夠完成,能夠看出其靈活性。 

相關文章
相關標籤/搜索