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來區分是種型別下的哪條記錄。
常見模組設計 OA許可權管理設計
oa系統許可權管理設計方案 不同職責的人員，對於系統操作的許可權應該是不同的。優秀的業務系統，這是最基本的功能。可以對 組 進行許可權分配。對於乙個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作許可權的話，是件耗時且不夠方便的事情。所以，系統中就提出了對 組 進行操作的概念，將許可權...
常見模組設計 許可權管理（auth）
drop table if exists tky auth role create table tky auth role roleid mediumint 8 unsigned not null auto increment comment 編號 title char 30 not null de...
常見模組設計 許可權管理（二）
許可權設計 基於角色的許可權設計 這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，所以微軟就設計出這種方案的通用做法，這種方案對於每乙個操作不做控制，只是在程式中根據角色對是否具有操作的許可權進行控制 這裡我們就不做詳述 許可權設計 基於操作的許可權設計 這種模式下每乙個操作都在資料...