在權(quán)限系統(tǒng)中，功能（權(quán)限）是最小的單位，比如起草新聞、編輯新聞、審核新聞、刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞、編輯新聞等功能集合，而責(zé)任編輯他可能就有更多的權(quán)限，比如除了新聞編輯的功能，還有審核新聞、刪除新聞等功能，給張三賦予新聞編輯的角色（其實我更愿意說把張三加入到新聞編輯這個角色中去），張三就可以起草新聞、編輯新聞了，給李四賦予責(zé)任編輯的角色，李四就可以起草新聞、編輯新聞、審核新聞、刪除新聞了。

　　我們來看看版本一的解決方案：

　　我們來模擬一下上面的數(shù)據(jù)：

　　用戶信息表：

　　角色表：

　　角色用戶表：

　　功能表：

　　角色功能表：

　　我們來看看如何判斷一個用戶具有某個功能權(quán)限：

　　首先在用戶張三登錄的時候，獲取張三的全部功能列表：

Select FunctionID From 角色功能表 Where RoleID In (Select RoleID From 用戶角色表 Where UserID=’U1’)

　　這樣就可以得到張三的全部功能列表Functions，在起草新聞的頁面我們就可以做如下判斷：

Functions.Contain(‘F1’);//當(dāng)然你可以把這個’F1’定義成一個常量：NewsFunction.Draft

　　如果為true就說明張三有起草新聞的權(quán)限。

　　當(dāng)然對于web應(yīng)用，您可以把Functions 用session保存起來，以避免每打開一個頁面都去數(shù)據(jù)庫中獲取。

　　似乎看起來是一個不錯的解決方案。

　　還是新聞系統(tǒng)，最初新聞系統(tǒng)沒有分類，但是隨著新聞的增加，沒有分類的新聞看起來總是亂的，于是張三和李四給新聞添加了分類A、分類B，還是由張三負責(zé)起草，李四負責(zé)審核，以后又添加了更多的分類，并且也增加了人手，這個時候就有新的要求出來了：希望張三只負責(zé)分類A的起草，分類B的起草交給其他人做，李四呢也只負責(zé)分類A的審核（就相當(dāng)于是一個欄目的責(zé)任編輯）。

第二部分：http://tubo.cnblogs.com/archive/2005/09/02/228828.html