第一部分請參看：
針對這樣的需求，版本一就無能為力了（當然你也可以增加幾個功能：比如分類
a的新聞起草和分類
b的新聞起草，再把這個功能新增到相應的角色裡面去，但是這個應該不是我們要得解決方案吧，不過版本二也是基於這個思想來解決的）。
其實比新聞更好的例子是論壇板塊的版主。
下面是版本二的解決方案：
在版本二的功能表中加入了乙個
resourcetype
這個字段，這個字段用來表示對某個資源的分類（比如新聞），我們同樣來模擬一下（新聞分類a的
resourcetype
為：nta
，分類b
為：ntb）：
功能表：
functionid
resourcetype
functionname f1
nta起草新聞：分類a
f2 nta
編輯新聞：分類a
f3 nta
審核新聞：分類a
f4 nta
刪除新聞：分類a
f1 ntb
起草新聞：分類b
f2 ntb
編輯新聞：分類b
f3 ntb
審核新聞：分類b
f4 ntb
刪除新聞：分類b
然後在角色表新增相應的角色，在角色功能表中新增對應的功能。
獲取functions
的語句也相應地做變化：
select functionid+
『，』+ resourcetype from
角色功能表
where roleid in (select roleid from
使用者角色表
where userid=』u1』)
許可權的判斷也就變成：
functions.contain(『f1,nta』);
在新新增乙個分類的時候，同時也在功能表中增加相應的記錄（當然不是在資料庫裡面直接新增，由和功能相關的函式來新增）。
使用這種解決方案可以簡單地對有分類的應用（比如論壇系統）的每個分類實行不同的控制（比如
vip板塊，就只能擁有
vip角色的使用者才能瀏覽、發表等，而其他板塊只要是註冊使用者就可以使用了）。
在實際應用中
functionid
並不是隨便的乙個字串，而是進行了編碼，其編碼中包含了模組
id以及能夠體現出父子關係，舉個例子來說：對於論壇系統，我們給它乙個模組id為
」30」
，論壇的功能我們先分成
2類，一類是管理類（比如刪除帖子），一類是使用類（比如發帖、回帖、瀏覽帖子等），給管理類乙個編碼：
01，使用類乙個編碼：
02，我們就對
functionid
進行如下的編碼：
300101
：刪除帖子
300201
：發帖
300202
：回帖
300203
：瀏覽帖子
對於資源（比如某個板塊
1，板塊的
id為：
01），我們可以組合出如下的
functions
（當然這個組合你也可以不用逗號分隔，用其他的組合方式也可以，不過不要產生歧義）：
300101,01
：板塊1
刪除帖子的功能
300201,01
：板塊1
發帖的功能
……對於roleid
也是採用的編碼方式，也能體現角色的父子關係，也可以實現角色功能的繼承等（當然獲取角色功能列表的
sql語句就不是現在這麼簡單了）。在我現在的應用裡面沒有實現角色的繼承（雖然角色的編碼體現出了角色的父子關係）。
許可權設計（二）
第一部分請參看 針對這樣的需求，版本一就無能為力了 當然你也可以增加幾個功能 比如分類a的新聞起草和分類b的新聞起草，再把這個功能新增到相應的角色裡面去，但是這個應該不是我們要得解決方案吧，不過版本二也是基於這個思想來解決的 其實比新聞更好的例子是論壇板塊的版主。下面是版本二的解決方案 在版本二的功...
基於角色的許可權設計（二）
針對這樣的需求，版本一就無能為力了 當然你也可以增加幾個功能 比如分類a的新聞起草和分類b的新聞起草，再把這個功能新增到相應的角色裡面去，但是這個應該不是我們要得解決方案吧，不過版本二也是基於這個思想來解決的 其實比新聞更好的例子是論壇板塊的版主。下面是版本二的解決方案 在版本二的功能表中加入了乙個...
常見模組設計 許可權管理（二）
許可權設計 基於角色的許可權設計 這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，所以微軟就設計出這種方案的通用做法，這種方案對於每乙個操作不做控制，只是在程式中根據角色對是否具有操作的許可權進行控制 這裡我們就不做詳述 許可權設計 基於操作的許可權設計 這種模式下每乙個操作都在資料...