1． 什麼是權限？？
l 很多人理解的權限就是用戶的登錄限制，但事實上權限可能涉及到的遠不止如此而已，權限就是在請求我們系統的一個服務(請求地址，請求方法，請求Action，請求WebService等)的時候，當在請求之前的時候我們先要去校驗你這個用戶有沒有訪問當前這個請求的權力，如果你有這個權力的話，我們就讓你訪問，否則你訪問不了這個請求。
2． 基於角色的設計
權限裏面最重要的實體也就只有三個(用戶，角色，操作)，他們之間最重要的也就是實體的關係，如果我們把他們三個之間的關係弄清楚了，權限這個模塊你基本就算搞定了。
（一個人可以有多個角色，一個角色可以被多個人擁有），怎麼來體現是多對多的關係呢，我們只能加一箇中間的關聯表。那麼表結構如下：
這種設計方案的缺點就是權限控制力度小，如果時間長的話中間表會變得很龐大，很冗餘，權限控制不精確。
3． 基於操作的設計
(1)什麼是操作的設計呢？就是把我們系統裏面的每一個動作都抽象出來抽象成一個操作(Action)，當我們點擊某一個按鈕的時候就是一個操作，一個動作，只要是我們對網站（或者系統）做任何的操作就是一個動作(Action)，那麼這個動作我們當前的用戶有沒有權力去操作，只有當動作和用戶關聯起來了，就允許我們去訪問這個動作。
(2)如果按照上面這種設計的話，那麼我們的動作將會非常的多，如果一個稍微大點的系統的話，那麼這個動作就不知道多到哪裏去了，這樣的話我們的Action這張表的數據就會非常的大，這樣還是不會達到我們的需求的，這種設計模式的表結構如下：
4． 基於角色-操作的設計
(1)通過4的設計方案我們能夠感覺到如果那樣設計的話Action這張表的數據將會非常的大，那麼我們能不能針對這個問題解決一下呢，當然是可以的，我們可以對這個動作（Action）再進行一次分組，這時候我們就提出來了角色，那麼角色是怎麼一回事呢，請繼續看。
(2)角色：只要你創建一個角色，這個角色就會關聯一組動作，那麼如果只要用戶加入這個角色，那麼這個角色關聯的所有動作是不是用戶也都具有了呢，也就是你都可以去訪問這個角色下面關聯的這組動作。所以角色也可以說成是動作的分組。
(3)那麼我們把角色和操作柔和到一塊，這種設計方式的表結構如下：
5． 將4和5組合起來的權限設計
(1)上面基於角色-權限的設計可能大部分時候已經可以很好地滿足系統的需求了，但是在面對某些複雜的、大型的系統時可能還不夠完美，例如比如說一個內容管理系統，對於某一些頻道某個用戶有修改的權限，而對於另外一些頻道沒有修改的權限，這時候我們需要設計更復雜的權限機制
(3)這個權限是在用戶和動作上面又加了一張表，這張表就是用戶的特殊權限表，在前面的設計中我們用戶和權限關聯是通過角色來關聯的(可以看第5種方法)，而現在我們用戶和動作之間又有了一張動作表。那麼這種設計方式的表結構如下：
我們可以看到在上圖中添加了UserAction表，使用此表來添加特殊用戶的權限，改表中有一個字段HasPermission可以決定用戶是否有某種操作的權限，改表中記錄的權限的優先級要高於UserRole中記錄的用戶權限。這樣在應用程序中我們就需要通過UserRole和UserAction兩張表中的記錄判斷權限。