? ? ? 對于一個有N個管理模塊的WEB后臺程序，如何為管理員分配權限，又如何在表中體現出來，可能每個人都有自己的實現過程。我作為一個菜鳥，搜集了一些資料，在這里做一下整理。
? ? ?前題：五個模塊；兩個組；幾個用戶。權限分配。
? ? ?我記得我第一次做這個的時候，當然網站比較簡單。一張表搞定，用USER_TYPE區分1234為不同的身份組（組的字典表都沒有做，程序中用注釋體現
），然后跟著五個字段，由0和1表示這個家伙有沒有管理權限。一切按著需求來，0和1的標識對于一個小網站來說已經夠用了，其實屬于一個假的權限指派，結果大家都想的到，因為對于一個用戶來講他只有可見或不可見兩個層面，而不存在可管理不可管理的真實權限。當然BOSS不知道，而我為了防止敲URL地址直接訪問，不得不在每個頁面都做驗證。雖說騙過了BOSS，真正悲劇的在于以后模塊的越來越多，每加一個模塊我就得跟加一個字段，這應該就是最讓人無法忍受的地方了。
? ? ?簡單歸簡單，簡單到無腦的設計。缺陷也很致命：
-
隨著功能的增加而增加表示權限的字段，DBA看見估計已經哭的不成人樣了。
-
每個管理員對于增刪改查等操作根本無法做出細化的權限分配。
? ? ? 對于這個加字段的方法，我想可以用一個字段，里面存放JSON數據字符串而表示，這樣在存取的時候多一步解析，看起來“完美”的解決了這個隨著模塊的增加而加字段的問題。麻煩歸麻煩點，總體還能正常工作。畢竟是權限要求細化程度不高的小站。而哪一天BOSS說給我把誰誰變成哪個組，要哪些管理權限，只能看，不能增加不能刪除。好吧，還好，涉及用戶不多，我在網頁上多做判斷好了，把增加和刪除不顯示出來。看起來我又挺過去了。
? ? ?但這總歸不是辦法，我明白了這個權限表設計的只能算是失敗的。
? ? ?怎么樣的設計才是完美的呢？
? ? ?回到需求上來，幾個模塊，幾個組，一批用戶。
? ? ?權限針對的管理對象是模塊，而一個模塊最少需要四種管理手段，即傳統的增刪改查。一個組擁有這個模塊的所有僅限，另一個組只擁有該模塊的查看瀏覽權限。如何設計？
? ? ?好在我找到了比較合適的方法。權限表的設計由模塊做為對象。
? ? ?組ID,模塊ID,ADD,MODI,DEL等幾個主要字段，0和1區分是否有管理權限。用戶只要指定組，就獲取了某一種管理權限。這樣的設計在后期增加模塊的情況下只需要為某個組增加幾個數據記錄而已，為組ID做個索引，還是有速度優化空間的。而更大的好處就是權限被細化了。看起來很完美的解決方案。
? ? ?只是看起來。
? ? ?如果哪天為了增加個臨時體驗帳號。如何是好？如果哪天組被刪除掉了，如何是好？
? ? ?我擦，組都沒了，我的用戶都沒權限了。
? ? ?失敗了？顯然是的。
? ? ?簡單的改動一下，把組ID換成USER_ID，好了，組沒了就沒了吧。把組又細化到人身上，人對于模塊擁有哪些權限，有五個模塊就會出現關于這個USER_ID的五條記錄，一個矩陣。說回來，這個組怎么辦？
? ? ?組只是一個抽象的概念，如果在網頁上表示這么個矩陣：
? ? ?模塊一：checkbox, checkbox, checkbox
? ? ?模塊二：checkbox, checkbox, checkbox
? ? ?模塊三：checkbox, checkbox, checkbox
? ? ?模塊四：checkbox, checkbox, checkbox
? ? ?對于組的權限只是一個簡單的JS效果，把某些CHECKBOX搞成選中狀態就OK了。這樣可以做到非常人性化，每個模塊的權限可以加上兩個日期，起始日期，結束日期，臨時VIP就出來了，月會員制。
? ? ?勾選了組，自動選中一些CHECKBOX，我再把CHECKBOX全點掉，這貨屬于管理員組，但沒有一點權限。誰說同一個組的人權限必須相同呢？
關于用戶組和權限的表結構設計
