使用者表結構的設計,算是整個應用架構的基石。如果基石不穩,待到後面需求跟進了發現不能應付,回過頭來反覆修改使用者表,要大大小小作改動的地方也不少,甚至有些情況下無從下手,因此我們應該怎麼設計使用者表呢?
需求分析
- 多種登入方式:包括手機號、微信、QQ、微博等;
- 可進行繫結和解綁或者更換繫結:使用者使用任意方式登入後可繫結和解綁或者更換繫結其他 登入授權;
- 支援unionid(針對QQ/微信等):如果開發者擁有多個移動應用、網站應用和公眾帳號,可透過獲取使用者基本資訊中的unionid來區分使用者的唯一性,因為只要是同一個微信開放平臺帳號下的移動應用、網站應用和公眾帳號,使用者的unionid是唯一的。
使用者表設計
1. 使用者主表 users
欄位 | 型別 | 鍵 | 為空 | 預設 | 備註 |
---|---|---|---|---|---|
id | int | PRI | no | 使用者唯一索引 | |
name | varchar | no | 使用者暱稱 | ||
avatar_url | varchar | yes | 頭像地址 | ||
phone | varchar | UNI | yes | 手機號 | |
password | varchar | yes | 密碼 | ||
created_at | timestamp | no | 建立時間 | ||
updated_at | timestamp | yes | 更新時間 |
使用者表主要用於儲存使用者資訊,以及手機號登入認證。
2. 第三方使用者資訊表 oauths
欄位 | 型別 | 鍵 | 為空 | 預設 | 備註 |
---|---|---|---|---|---|
id | int | PRI | no | 唯一索引 | |
user_id | int | no | 使用者ID | ||
oauth_type | varchar | no | 第三方登陸型別 weibo、qq、wechat等 | ||
oauth_id | varchar | no | 第三方uid 、openid等 | ||
unionid | varchar | yes | QQ/微信同一主體下Unionid 相同 | ||
credential | varchar | yes | 密碼憑證/access_token(目前更多是儲存在快取裡) |
用於儲存第三方登入使用者授權後的資訊。
3. 擴充套件使用者表資訊 users_extends
欄位 | 型別 | 鍵 | 為空 | 預設 | 備註 |
---|---|---|---|---|---|
id | int | PRI | no | 唯一索引 | |
user_id | int | no | 使用者ID | ||
field | varchar | no | 擴充套件欄位 | ||
value | varchar | yes | 擴充套件欄位值 |
對於使用者表中沒有維護的資料例如生日 brithday
、等級level
等資訊可以儲存在當前資訊表。
使用場景
場景一: 先使用手機號註冊,之後繫結微信、微博、QQ等第三方賬號;
註冊成功後users表:
id | name | avatar_url | phone | password | created_at | updated_at |
---|---|---|---|---|---|---|
1 | 馮先森001 | null | 186XXXXX | XXXX | 2018-10-01 00:00:00 | 2018-10-01 00:00:00 |
使用者暱稱及頭像可在註冊時要求新增也可自動生成。
之後根據使用者id繫結/解綁/更換繫結相應第三方賬號QQ、微博、微信等賬號
場景二:先使用微信、微博、QQ等第三方賬號註冊,之後再繫結手機及其他未繫結第三方賬號;
以微信登入為例,第一次繫結成功後,users和oauths。
透過第三方授權獲取的使用者資訊(暱稱、頭像)建立users資料:
id | name | avatar_url | phone | password | created_at | updated_at |
---|---|---|---|---|---|---|
2 | 微信暱稱 | avatarUrl | null | null | 2018-10-01 00:00:00 | 2018-10-01 00:00:00 |
根據使用者ID及第三方授權獲得的資訊建立oauths資料
id | user_id | oauth_type | oauth_id | unionid | credential |
---|---|---|---|---|---|
1 | 2 | o2sck0XXXXXXR-NDA | osssck0XXXXXXR-NDA | null |
其中微信登入可分為wechat
微信移動應用,official_account
微信公眾賬號,mini_program
微信小程式,同一主體的情況下unionid是一致的。
之後再根據使用者ID繫結手機及其他未繫結第三方賬號。
優缺點
優點:
- 可擴充套件;
- 易維護;
- 使用者表簡潔明瞭;
缺點:
會產生一個人有多個賬號的情況。
例如:當使用者用手機號註冊後,退出登入,再使用微信授權登入就會產生2個users資料(反之亦然),但是本質來說是一個使用者。
解決方法:
- 當使用者第一次使用微信授權繫結的之後,彈出繫結手機頁(可跳過,不強制繫結),如果手機號已經存在則告訴使用者,“該手機號以存在,無法繫結”。
- 當使用者使用手機號直接註冊的賬戶登入後,授權繫結上述微信時提示使用者“此賬號已存在繫結”;
有時候適當的衝突是無法避免的,可以使用友好的設計與話語增加使用者體驗。
Todo
- users_extends表的使用舉例。
- 會員系統
本作品採用《CC 協議》,轉載必須註明作者和本文連結