1.基於 RBAC（Role-based Access Control）許可權訪問控制。也就是說一個使用者可以有多個角色，一個角色可以有多個許可權，通過將角色和許可權分離開來提高設計的可擴充套件性，通常一個使用者有多個角色，一個角色也會屬於多個使用者（多對多），一個角色有多個許可權，一個許可權也會屬於多個角色（多對多）。

2.最簡單版本
假設：我們拿到一個使用者物件，
可以通過：使用者id –>角色id–>角色名稱（什麼角色）–>許可權id –> 許可權標識 –>獲取許可權。最終獲取許可權獲取角色資訊。

角色：可以簡單理解為許多許可權的集合。比如二級管理員，三級管理員。

3.使用者組模式
如果使用者數量比較龐大，可以加入使用者組模式。需要給使用者分組，每個使用者組內有多個使用者，可以給使用者授權外，也可以給使用者組授權。終端使用者擁有的所有許可權 = 使用者個人擁有的許可權+該使用者所在使用者組擁有的許可權。（這個設計類似 svn 中的使用者許可權，比如，將一個svn使用者加入到 group中，然後設定group的許可權，以後加入更多的使用者，就不用再一一設定使用者的許可權了。）

4.許可權分類
大部分是針對功能模組，比如對資訊記錄的增刪改（資訊狀態修改，檔案的刪除修改等），選單的訪問，輸入框，按鈕的可見性，是否可以新增下級管理員等。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成“使用者-角色-許可權-資源”的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。

5.完整版
請留意許可權表中有一列“許可權型別”，我們根據它的取值來區分是哪一類許可權，如“MENU”表示選單的訪問許可權、“OPERATION”表示功能模組的操作許可權、“FILE”表示檔案的修改許可權、“ELEMENT”表示頁面元素的可見性控制等。

優點：（1）不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。
（2）方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立一個新的關聯表“許可權XX關聯表”，並確定這類許可權的許可權型別字串。

這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增一個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的ID，許可權表通過“許可權型別”和這個ID來區分是種類型下的哪條記錄。