針對這樣的需求，版本一就無能為力了（當然你也可以增加幾個功能：比如分類a的新聞起草和分類b的新聞起草，再把這個功能新增到相應的角色裡面去，但是這個應該不是我們要得解決方案吧，不過版本二也是基於這個思想來解決的）。
其實比新聞更好的例子是論壇板塊的版主。
下面是版本二的解決方案：
在版本二的功能表中加入了乙個resourcetype這個字段，這個字段用來表示對某個資源的分類（比如新聞），我們同樣來模擬一下（新聞分類a的resourcetype為：nta，分類b為：ntb）：
功能表：
functionid
resourcetype
functionname f1
nta起草新聞：分類a f2
nta
f3 nta
審核新聞：分類a f4
nta刪除新聞：分類a f1
ntb起草新聞：分類b f2
ntb
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語句就不是現在這麼簡單了）。在我現在的應用裡面沒有實現角色的繼承（雖然角色的編碼體現出了角色的父子關係）。
基於角色的許可權設計
基於角色的許可權設計 一 在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任...
基於角色的許可權設計
在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任編輯他可能就有更多的許可權...
基於角色的許可權設計
基於角色的許可權設計 一 在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任...