繼續探討數據庫權限管理設計

通常的Web系統和MIS系統權限管理設計大概有這幾種模式：
用戶+組+角色+權限
用戶+組+權限
用戶+角色+權限
用戶+權限

最近看了別人的設計方法，大多以「整數」來表示權限值，如添加、瀏覽、刪除和修改，分別用一、二、四、8這幾個整數來代替，不過，各人的作法有所不一樣，舉例以下：

1.用2的n次冪組成權限值的集合，如一、二、四、八、16...，某用戶的權限值爲其子集中的整數之和，如 7=1+2+4，5=1+4。若是要從數據庫檢索包含某幾種權限的用戶，則先把這幾種權限值相加，假設和爲k，而後select * from table where 1 and 用戶權限值 = 'k'；若是要判斷某用戶有哪些權限，則取出其權限值k，分別用k&1,K&2,K&4,k&16...,若是爲真，則表示有值等於「&」右邊整數的權限，例如，若是k&4爲真，則此用戶有權限表中值等於4的權限；

 

2.用質數二、三、五、七、11...組成權限集合，某用戶的權限爲其子集中各整數的乘積，如 210 = 2*3*5*7,我以爲這種方法頗有趣，難點在於如何分解質因數；但我有些不認同原做者的提法，他認爲權限之間可能存在包含關係，如某用戶有刪除權限，則其必定有瀏覽權限，要否則就無法刪除，事實確實是這樣，不過我認爲這樣太複雜了，容易出錯，我以爲權限最好是「原子」的，互不干擾，也就是說某用戶有刪除權限而沒瀏覽權限則其沒法進行刪除操做，由於他看不到東西，解決這個矛盾的關鍵是在給用戶賦權時，把瀏覽權限也賦給他；

 

3.不用整數，而是用「向量表」方法（也許我說的不必定對），把全部可能的權限按必定的順序排列，如添加、瀏覽、修改、刪除...，用戶的權限值爲固定100位長度的字符串，如100010100001....01，從左起每一位對應一種操做權限，若是有這種權限，則此位的值爲1，反之，則爲0，做者之因此把用戶權限值固定爲100位，我想是考慮到升級問題，但我認爲這還不夠科學，我認爲用戶的權限值長度應小於權限個數，舉例以下：
權限排列表：添加、瀏覽、修改、刪除，用戶A有添加和瀏覽的的權限，則其權限值爲11，用戶B有瀏覽和修改的權限則其權限值爲011，用戶C有瀏覽和刪除的權限則其權限值爲0101，這樣設計的好處爲：當權限表中增長別的權限時，不會影響用戶表或角色表；

 

4.我曾經的作法，在後臺管理中把權限分爲兩大類：欄目權限和操做權限，每一個欄目對應一個目錄，操做權限細分爲瀏覽、添加、修改和刪除，用戶進入系統後首先判斷有沒有欄目權限，而後判斷有沒有操做權限，判斷欄目權限相對簡單一些，首先獲取訪問頁面的路徑path，而後分解出目錄，對應用戶擁有的目錄權限，若是此目錄包含在用戶有權管理的目錄數組中（從數據庫取出），則其有進入此目錄的權限，不然，沒有，然而，在判斷操做權限好象有些麻煩，但忽然想到添加、瀏覽、修改和刪除與個人文件命名規則是基本是對應的，但有點不一樣的是，我把添加和刪除的功能合併在一個文件中了，例如文件名爲proAddEdit.php，幸虧意識到修改文件時多了個傳遞參數id，因而，我用正則解決了這個問題，今天看來，這種方法彷佛過期了，由於不適應面向對象的思想和用框架體系來開發系統！