源位址
在web開發中關於許可權管理設計大抵涉及到兩個方面：一：功能方面許可權設計；二：資源方面許可權設計。二者比較來看，功能方面許可權的可重用性更高。
1.關於許可權：
說明：a.使用者-使用者角色-角色：可以構成乙個使用者角色許可權管理子模組，即1中最簡單的設計。
b.模組-模組許可權-許可權：可以構成乙個模組許可權管理子模組。注：這裡的描述有些欠缺，單獨的看待模組部分，應該描述為模組-模組功能-功能更為恰當。
c.將a和b同過角色許可權組合在一起就可以構成乙個使用者-角色-許可權的按照功能模組粒度劃分的許可權管理系統。
3.使用者-角色-許可權資料庫中表之間的關聯關係說明：
上述資料庫表的關係圖中的每一張表不涉及具體的字段內容，所具備的字段都是為了描述各個表之間的關聯關係。
實體表：使用者表，角色表，許可權表，模組表；
中間表：使用者角色，角色許可權，模組許可權表，用來解決多對多問題；
角色許可權表：涉及角色具備的許可權，該許可權是來自模組許可權，也就是符合2中的模組許可權。
關於角色許可權表是使用者-角色-許可權系統的乙個可擴充套件口。例如：角色許可權可以和許可權直接關聯，或者二者之間新增特定場景的其他表。
4.資料庫用例資料，使用使用者-角色-許可權系統
至此，使用者，角色，許可權的劃分就形成了，而且可以通過實際中需要的使用者，角色，許可權的管理程度，進行簡化或者增加表。
5.查詢使用者編碼為400900500的許可權
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
select
t_account.acccode, t_account.accname,
t_role.rolecode, t_role.rolename,
t_module_privilege.moduelcode,
t_module.moduelcode, t_module.moduelname,
t_privilege.pricode, t_privilege.priname
from
t_account, t_account_role, t_role, t_role_privilege, t_module_privilege, t_module, t_privilege
where
t_account_role.acccode=t_account.acccodeandt_account_role.rolecode=t_role.rolecode
and
t_account.acccode="400900500"
and
t_role_privilege.rolecode=t_role.rolecodeandt_role_privilege.mpid=t_module_privilege.mpid
and
t_module_privilege.moduelcode=t_module.moduelcodeandt_module_privilege.pricode=t_privilege.pricode
通過面的sql語句可以查詢到400900500使用者的許可權。
上述查詢僅僅說明各表之間的資料關聯關係，在實現開發中這樣的查詢避免使用。
關於使用者角色許可權管理有程式的開發系統，參見如：
Web開發中的使用者角色許可權設計總結
在web開發中關於許可權管理設計大抵涉及到兩個方面 一 功能方面許可權設計 二 資源方面許可權設計。二者比較來看，功能方面許可權的可重用性更高。1.關於許可權 說明 a.使用者 使用者角色 角色 可以構成乙個使用者角色許可權管理子模組，即1中最簡單的設計。b.模組 模組許可權 許可權 可以構成乙個模...
Web開發中的使用者角色許可權設計總結
在web開發中關於許可權管理設計大抵涉及到兩個方面 一 功能方面許可權設計 二 資源方面許可權設計。二者比較來看，功能方面許可權的可重用性更高。1.關於許可權 說明 a.使用者 使用者角色 角色 可以構成乙個使用者角色許可權管理子模組，即1中最簡單的設計。b.模組 模組許可權 許可權 可以構成乙個模...
使用者角色許可權設計思路
使用者角色管理作為每個管理系統所必備的模組，也是每個系統的基礎模組。網上有很多都稱作通用許可權管理系統，真的就通用麼？不一定吧，個人認為不管通用與不通用，能滿足自己系統的需求就ok了。廢話不多說 下面是乙個使用者角色許可權設計思路 1 不同職責的人員，對於系統操作的許可權應該是不同 2 可以對 組 ...