既然都決定要重寫了，那接下來就可以開始寫 Code 了……嗎？

答案是否定的。

首先，我們必須先回答一個問題。

誰是 User？是學生？是老師？還是行政人員？

他們都是 User。

學生是 User；老師是 User；行政人員當然也是 User。

如果是一年前的我，這時候就會說：欸！這題我會！把所有 User 塞進一張表就好了對吧！

我原本還想回去翻一年前留下來的專案規劃，看看當時的自己到底想了什麼。

結果翻了一輪 Notion。

有寫「使用 PostgreSQL」。
有寫「資料庫結構設計」。
有寫「規劃資料庫架構」。

但是——

我找不到當時的 Schema 了。

太好了我們沒救了 :D

那我就只好靠我對一年前自己的理解，來還原他大概會寫出什麼大便東西吧。
這邊我有個大膽的想法，我們來邀請一年前的我進來這個系列一起討論好了。
那我們這邊有請蘇同學。

（一頓奇妙操作把蘇同學通靈出來）

嗯？我怎麼在這裡？

老弟，好久不見，現在還有興趣搞數位校園嗎？

（撓頭）最近沒啥空，不對啊？你是誰啊？

喔，高二的你。

啊？是有聽說工程師都會通靈啦，但沒想到你真學會通靈了啊？

那必須。是說老弟，有沒有興趣跟著我一起做數位校園？

這麼好，你要帶我做嗎？那肯定好啊！

行，是說我剛剛在 Notion 裡沒有翻到你寫的 DBML，你有頭緒存哪了嗎？

dbdiagram.io？

我看看。
不錯，找到了。

不得不說，整體來說寫得不錯。
裡面有出現 salt，代表你有想到不能明文存密碼的問題，算是有在動腦。

……6。

只是有些東西沒想清楚，還沒辦法進系統。
改改基本可以用了，但今天先把 Users 處理好。

有些東西沒想清楚？怎麼說？

來看這邊，你這邊 Message.author_id 外鍵同時指向 Users.id 跟 Admin.id，差點讓我矇掉。
你想寫的是 author_id 可以從 Users 來，也可以從 Admin 來，對吧？
但照你現在這樣寫，這個 author_id 會需要同時滿足兩個外鍵約束，說直白一點，就是這個 ID 必須同時存在於 Admin 跟 Users 兩張資料表裡。
這應該不是你的原意，對吧？

嗯，確實不是我原本想表達的意思。

然後這邊你還可以想想 Admin 會有多少人，真的值得單獨開一個表進資料庫嗎？

撐死 2～3 人吧，那這樣硬編碼好像也可以。

同意，但有更好的解法。
這邊還有個 can_write_message，你想表達什麼，用你的話說看看。

就……可不可以發廣播啊。

嗯哼，那如果要表達可不可以處理報修呢？

那加一個 can_process_repair 欄位不就好了。

那總務處跟資訊中心要不要分開？

嗯……那開 can_process_general_repair 跟 can_process_pc_repair 兩個欄位？

那一般學生是不是不能確認廣播，是不是還要加 can_view_report？

嗯……確實。

然後你這邊這個名字也有小問題。

怎麼了？

view 是查看還是確認？

嗯，應該是確認，在這裡用 view 好像會跟 read 的意思混淆到。

嗯，這邊用 confirm 吧。

那就改成 can_confirm_report 吧。

可以。
接下來，算算你現在已經為了權限開幾個欄位了。

4 個？

嗯，那以後每多一個權限，你就再加一個欄位？
等哪天加到 10 個、20 個，你維護得動嗎？

位元算魔法？把全部權限塞進一個數字，這樣只要一個欄位就可以記載所有的權限了。

……

安怎？

好，沒事，你已經回答了第一個問題：權限怎麼擴充。

接下來要回答第二個問題：大量使用者的權限怎麼同步管理？

思考一下，當你新增了一個權限，全校有 100 個老師都需要這個權限，你要怎麼設定？全部重新一個一個給嗎？

大量使用者……權限……同步管理……

有想到什麼了嗎？

Discord 的身分組？

……好，你已經很接近答案了。

但這東西有一個正式的名詞，叫做 RBAC。
RBAC，Role-Based Access Control，基於角色的存取控制。

先把 Role 的權限設定好，然後把 Role 掛到 User 身上？

對，所以如果套回我們現在的問題呢？

……我們不用幫每個 User 設定 can_write_message？只要把這個權限掛到對應的 Role 上？

說得具體一點。

我們可以建立一個 Role 叫 teacher，當有新老師時就幫他掛上 teacher。這樣需要調整老師的權限時，我只需要更改 teacher 的權限，而不用一一更改每個老師的權限。

正確，恭喜入門 RBAC。

等等，所以照這樣說的話，剛剛的 Admin 也不用獨立開一張表，只需要設定一個 Role，然後掛到管理員身上就好了？

不錯，想得挺快的。

不過真正的問題其實不在管理員只有 2～3 個，而是 Admin 本身並不是另一種 User，它比較像是特定 User 擁有的一個 Role，而這個 Role 再帶著管理系統所需的權限。

權限跟著身分跑，而不是跟人跑？你想說這個對吧。

嗯哼，如果從行政系統的角度來看也是。
今天總務主任能處理總務處的事務，不是因為「A」這個人天生有這個權限，而是因為 A 現在擔任「總務主任」。
哪天換成 B 接任，權限也應該跟著職位一起換過去，不會留在 A 的身上。

有道理。