寫後台系統時，有個很複雜的難點在於「角色權限」。
難點在如何變得好擴充，又能讓整個後台系統容易分權。
如:A進到一個頁面，在這頁面只能看，不能編輯。
思考的角度
如果同時思考「頁面權限」和「新刪修查權限」，很容易陷入混亂。
因此，建議先有個 「這個系統主要是要幹嘛」 的概念，說不定根本不用權限，因為使用者就那幾個，或是只到頁面上的分權，先有了使用者需求是什麼，再來確定要用哪種方法。
在此，我想探討的會是「頁面權限」到「新刪修查權限」的作法。
考量到使用者操作的直覺，以「模組>功能>操作權限」這樣排。
如此一來，我們功能只要對到「查看、新增、編輯、刪除」，先解決了細部的部分。
再來就只要把模組與功能分類關聯即可。
資料表規劃
users:使用者，上面綁角色role_id，每個使用者都有一種角色。
roles:角色，用來設定權限用。
module_permissions:模組權限，用來綁定底下功能權限。
func_permissions:功能權限，用來綁底層的權限。
permissions:權限，用來綁func_permissions與permission_types的表。
permission_types:權限分類，可自行定義分類，如:查看、新增、編輯、刪除…等。
ps.資料表上的name欄位也能說是code、key值，就是在網頁上你要抓檢查用的。
以下做的這張表就能進行分權。因為是以功能劃分，所以之後如果有APP或其他前端介面，只要照著「模組>功能」這樣去設計一樣能夠適用。
如果一個A使用者進到「基礎管理>角色管理功能」頁面，只要檢查他的檢視權限有沒有，沒有就返回首頁即可。只要有勾取功能權限，那必有檢視的權限。
如果更新角色時，把module_permissions、func_permissions、permissions有關聯的清空再重新建立即可。
[補充]*代表多，1代表1，可以看出是一對多還多對一
如果想知道更多:[Day7] SQL server資料庫關聯 - SQL Server資料庫入門
更多階層的權限?
如果是巢狀的話也是可以，func_permissions加個func_permissions_parent_id欄位，就能變成巢狀了。
不過以現有系統架構來講，也是能偷吃步直接在name上說是功能A的XXX項目也是可以的。
通常不會有超過5階以上的頁面，不然使用者會迷路、功能分則過細也不好用，即使遇到也是能用上面兩種方法去克服。
然後，建議權限這種不要做成動態的樹，因為哪天要改會很麻煩，建議這種階層還是寫死，變動次數通常不會太多，寫的簡單些未來也好改。
如果是API權限如RESTful API ?
目前我還沒有想到比較好的解法，目前只想到能在送出去前免強撈資料表判斷。
在新、刪、修時都卡，而查則是盡量了，因為RESTful本身就容易查出一些原本不相干的資料，所以不好分權。
總結
花了兩小時左右打完了這篇文跟設計表，實際規劃後覺得權限這部分不算難，只是要想清楚系統到底要做什麼，再來跟PM或SA確定一種可以的結構去開發就行。
如今，網路上也有不同解答，如果有共事的工程師也能一起討論方法，讓這系統能順利產製便可以，千萬別執迷不悟硬幹阿@@…孩子。
然後我是用 https://dbdiagram.io/ 來畫下面那張圖的，很方便。
此外，也可以參考”以角色為基礎的存取控制”（Role-based access control，RBAC）
https://zh.wikipedia.org/wiki/%E4%BB%A5%E8%A7%92%E8%89%B2%E7%82%BA%E5%9F%BA%E7%A4%8E%E7%9A%84%E5%AD%98%E5%8F%96%E6%8E%A7%E5%88%B6
參考資料
http://www.chanpin100.com/article/110136
https://ithelp.ithome.com.tw/questions/10190444
https://zh.wikipedia.org/wiki/%E4%BB%A5%E8%A7%92%E8%89%B2%E7%82%BA%E5%9F%BA%E7%A4%8E%E7%9A%84%E5%AD%98%E5%8F%96%E6%8E%A7%E5%88%B6