最近專案中需要設計乙個許可權系統，收集了一下資料，許可權系統主要有兩種技術：acl(access control list)和rbac(role-based access control)。前者是將使用者直接和許可權關聯，並通過group來組織這些使用者，windows 系統的使用者許可權就應該屬於這一種（有待確認）。後者通過角色將使用者和許可權隔離開來，對角色賦予許可權，而乙個使用者就一種角色的乙個例項。
acl的優點是能夠直接針對使用者進行許可權設定，許可權設定較為靈活，每個使用者都可以完全不同，但是這也增加了管理員設定許可權的複雜性。rbac更便於使用者的管理。對於兩者的詳述和比較在不在此囉嗦，網上有很多相關資料。
下面就說我做的事情。
設計需求：
1. 以專案為單位的許可權控制；
2. 專案分為不同的小組，比如儀表組、dcs組等，每個組所使用的系統模組不同；
3. 每個小組下面又有不同崗位，比如儀表選型、樣本維護等。不同崗位的人員，對該小組對應的系統模組下的不同功能的使用許可權不同。
第2對應rbac的group，第3對應rabc的role，這一部分畫出了如下的資料庫er圖。
這中結構就是通常介紹rbac的通用結構，比較容易理解。從er圖中可以看出，許可權分配是以角色為單位，這是rbac的最主要的特點。同時，從很多資料中看到，rbac一般只做到功能級別的許可權控制，而對於更加細粒度的資料控制很難實現，比如細化到行資料，甚至是字段的操作許可權控制。
下面的這些需求就是讓我糾結了很久。
1. 對於同一崗位（角色）的不同人員（角色例項），能夠查詢該崗位的所有人員建立的資料，但是只能夠修改或刪除自己所建立的資料；
2. 對於非自己所建立的資料，只能訪問該資料的部分字段。
其實，第1條就是基於行資料的訪問控制，第2條就是基於欄位的訪問控制。為了滿足這兩項，新增了三張資料表，形成了下面的er圖。
「許可權類別」資料表相當於乙個列舉變數，包括 專案、組、角色、個人四個值，比如一項「樣本維護-刪除-樣本」（角色-操作-功能）的操作許可權的許可權類別屬於「個人」，那麼一行樣本資料只能夠由該資料的建立者刪除；如果資料「角色」，那麼該資料可以由所有的樣本維護角色的人員來刪除。這樣，就可以滿足第1條需求了。
上述僅為自己做這個許可權設計的初始想法，還未驗證，也未進行編碼，歡迎各位拍磚！
基於角色的許可權管理系統資料庫設計
表名 使用者表 user 主鍵 id 備註 這張表唯一要求就是檢索速度？如果該張表每天有一千萬次的訪問量，該如何設計優化？filedname filedtype mainfileddescription idname otherfiled int自動增長列,主鍵約束 varchar 20 not n...
使用者 角色 許可權資料庫設計
分類 linux 許可權管理 許可權管理，主要是人員和許可權之間的關係，但是如果讓人員直接和許可權打交道，那麼許可權的賦值 許可權的撤銷以及許可權的變動會非常的麻煩，這樣引入了，角色，給角色賦許可權，然後給使用者分配角色。這個設計主要涉及6張表，使用者表,用於儲存使用者的所有資訊 許可權表，用於儲存...
基於角色的許可權設計
基於角色的許可權設計 一 在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任...