您好,登錄后才能下訂單哦!
這篇文章主要講解了“數據庫通用權限管理怎么設計”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“數據庫通用權限管理怎么設計”吧!
一,前言
權限管理系統的應用者應該有三種不同性質上的使用:
A、使用權限
B、分配權限
C、授權權限
本文只從《使用權限》和《分配權限》這兩種應用層面分析,暫時不考慮《授權權限》這種。
二,初步分析
用戶和角色
說到權限管理,首先應該想到,當然要設計一個用戶表,一個權限表。這樣就決定了一個人有什么樣的權限。
做著做著就會發現這樣設計太過繁瑣,如果公司里面所有員工都有這樣的權限呢,每一個人都要配置?那是一件很痛苦的事情。因此再添加一個角色表,把某些人歸為一類,然后再把權限分配給角色。角色屬下的用戶也就擁有了權限。
用戶、角色之間的關系是一個用戶可以對應多個角色,一個角色可以對應多個用戶。多對多關系。
所以需要一個中間表,相信大家都很熟悉,自然不會有疑問。
應用場景
有了用戶和角色以后,就需要設計應用場景,比如一個應用程序有幾大模塊(系統模塊、項目管理模塊、銷售模塊),類似這樣的模塊就是一種應用場景,常見的還有 菜單、操作 等等。
假設現在我們設計好了,應用場景包括 模塊、菜單和操作,那么應該有以下六種關系:
一個用戶可以對應多個模塊,一個模塊可以對應多個用戶。多對多關系。
一個用戶可以對應多個菜單,一個菜單可以對應多個用戶。多對多關系。
一個用戶可以對應多個操作,一個操作可以對應多個用戶。多對多關系。
一個角色可以對應多個模塊,一個模塊可以對應多個角色。多對多關系。
一個角色可以對應多個菜單,一個菜單可以對應多個角色。多對多關系。
一個角色可以對應多個操作,一個操作可以對應多個角色。多對多關系。
于是建立六張表來維護這六種關系。
這樣設計看起來沒什么問題。是的,如果沒有加入新的關系的話,這樣是已經可以滿足大部分的需求了。
可是如果就是如果,新的關系(需求)往往會加入到系統進來。這個時候就需要再建立一個新的表。系統的復雜度也隨著增加。
可以看出,這樣的設計有幾個問題:
數據表設計太復雜
應對系統方案過于固定
三,把問題簡單化
不同的應用場合,你可能會想出不同的需求,提了一個新的需求以后,可能會發現原來的設計沒方法實現了,于是還要添加一個新的表。這也是上面所提到的問題。
其實不必想得那么復雜,權限可以簡單描述為:某某主體 在 某某領域 有 某某權限
主體可以是一個模塊,可以是一個頁面,也可以是頁面上的按鈕
權限可以是用戶,可以是角色,也可以是一個部門
領域可以是“可見”,可以是“只讀”,也可以是“可用”(如按鈕可以點擊)
其實就是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"。
如果不清楚的可以看下圖:
數據庫設計:
感謝各位的閱讀,以上就是“數據庫通用權限管理怎么設計”的內容了,經過本文的學習后,相信大家對數據庫通用權限管理怎么設計這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。