"表單每人每年都需要上來填" 所以表單這件事情本身有綁活動嗎？
還是就單純的user+年，等於這張表有點像每年員工的自評表這樣？
反正員工每年就上來填寫自評，你要存取這件事情？

如果就像我說的那樣的話，那其實你等於存取就是拿使用者id, 跟今年的年度來撈出這表的自評內容或者用left join,快速找出哪些員工還沒填寫自評.

1️⃣ 兩種設計方式
設計方式
說明
優點
缺點
用使用者帳號當 Primary Key（自然鍵）
直接用 username 或 email 當主鍵
‧ 少一個欄位，不用 JOIN 就能取得帳號‧ 查詢語意直覺
‧ username 變動會牽連到外鍵表 (很痛)‧ PK 長度較長 → index、join 效能差‧ 不適合複合情境（可能有多筆相同帳號對應不同記錄）
用使用者表的流水號/ID 當 Primary Key（代理鍵）
用 user_id (INT/BIGINT) 做 PK，username 放在 users 表
‧ Index 短小、查詢 join 效能好‧ 不受 username 改名影響‧ 擴充性佳
‧ 查詢需要 JOIN users 才拿到 username
2️⃣ 業界實務建議
• 幾乎所有大型系統（電商、社交、ERP）都傾向用「代理鍵（流水號/UUID）」作為 PK。
• username、email 之類資料應該放在「業務層邏輯」欄位，並加上 唯一索引（UNIQUE INDEX） 去保證不重複，而不是 PK。
• 因為 username 可能會改名（例如用戶申請更改帳號、改綽號、改綁定信箱），用自然鍵做 PK 會很麻煩。

⸻

3️⃣ JOIN 的顧慮
• JOIN 的確多了一個步驟，但用整數型 PK JOIN 效能幾乎不會差，反而比用文字 PK 好很多。
• 如果查詢常常需要帳號名稱，可以在資料表直接存一份冗餘欄位（例如 username_cache），或者在查詢層做 VIEW 或 MATERIALIZED VIEW 來減少 JOIN。

⸻

4️⃣ 建議做法（綜合）
• 在使用者主表：
• user_id (INT/BIGINT, Primary Key, Auto Increment or UUID)
• username (VARCHAR, UNIQUE INDEX)
• 在你的新資料表：
• id (Primary Key, Auto Increment)
• user_id (Foreign Key → users.user_id)
• 其他資料欄位
• 如果需要 username 很常用：
• 在查詢時 JOIN users 表
• 或在新表多加一個 username 作快取，定期同步

⸻

5️⃣ 簡短結論

✅ 用「使用者表的流水號/ID」做 Foreign Key + Primary Key。
❌ 不建議用 username 當 PK。
💡 需要顯示 username 再 JOIN 或做快取。