今天面試談到乙個許可權管理，總結下許可權管理模組的資料庫部分設計
我們比較常見的就是基於角色的訪問控制，使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有多個角色，乙個角色擁有多個許可權。這樣，就構造成「使用者-角色-許可權」的授權模型。在這種模型中，使用者與角色之間、角色與許可權之間，通常都是多對多的關係。如下圖：
基於這個，得先了解角色到底是什麼？我們可以理解它為一定數量的許可權的集合，是乙個許可權的載體。例如：乙個論壇的「管理員」、「版主」，它們都是角色。但是所能做的事情是不完全一樣的，版主只能管理版內的貼子，使用者等，而這些都是屬於許可權，如果想要給某個使用者授予這些許可權，不用直接將許可權授予使用者，只需將「版主」這個角色賦予該使用者即可。
但是通過上面我們也發現問題了，如果使用者的數量非常大的時候，就需要給系統的每乙個使用者逐一授權(分配角色)，這是件非常繁瑣的事情，這時就可以增加乙個使用者組，每個使用者組內有多個使用者，除了給單個使用者授權外，還可以給使用者組授權，這樣一來，通過一次授權，就可以同時給多個使用者授予相同的許可權，而這時使用者的所有許可權就是使用者個人擁有的許可權與該使用者所在組所擁有的許可權之和。使用者組、使用者與角色三者的關聯關係如下圖
通常在應用系統裡面的許可權我們把它表現為選單的訪問(頁面級)、功能模組的操作(功能級)、檔案上傳的刪改，甚至頁面上某個按鈕、是否可見等等都屬於許可權的範疇。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成「使用者-角色-許可權-資源」的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。如下圖：
這裡特別需要注意以下許可權表中有一列「powertype(許可權型別)」，我們根據它的取值來區分是哪一類許可權，可以把它理解為乙個列舉，如「menu」表示選單的訪問許可權、「operation」表示功能模組的操作許可權、「file」表示檔案的修改許可權、「element」表示頁面元素的可見性控制等。
這樣設計的好處有兩個。一、不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）；二、方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立乙個新的關聯表「許可權xx關聯表」，並確定這類許可權的許可權型別字串即可。
需要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增乙個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的id，許可權表通過「許可權型別」和這個id來區分是種型別下的哪條記錄。最後擴充套件出來的模型完整設計如下圖：
注意上面我額外增加了乙個操作日誌表；
隨著系統的日益龐大，為了方便管理，如果有需要可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：當遇到有多個子公司，每個子公司下有多個部門，這是我們就可以把部門理解為角色，子公司理解為角色組，角色組不參於許可權分配。另外，為方便上面各主表自身的管理與查詢，可採用樹型結構，如選單樹、功能樹等，當然這些可不需要參於許可權分配。
另外之前用過乙個比較簡單的許可權管理資料庫設計，乙個使用者只有乙個角色，只需要五個表，改天再分享。。。。
使用者許可權管理模組的資料庫設計
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
使用者許可權管理模組的資料庫設計
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
使用者許可權管理模組的資料庫設計
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...