用户表结构的设计，算是整个应用架构的基石。如果基石不稳，待到后面需求跟进了发现不能应付，回过头来反复修改用户表，要大大小小作改动的地方也不少，甚至有些情况下无从下手，因此我们应该怎么设计用户表呢？
需求分析
- 多种登录方式：包括手机号、微信、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 表的使用举例。
- 会员系统
