用户表结构的设计，算是整个应用架构的基石。如果基石不稳，待到后面需求跟进了发现不能应付，回过头来反复修改用户表，要大大小小作改动的地方也不少，甚至有些情况下无从下手，因此我们应该怎么设计用户表呢？
需求分析
- 多种登录方式：包括手机号、微信、QQ、微博等；
- 可进行绑定和解绑或者更换绑定：用户使用任意方式登录后可绑定和解绑或者更换绑定其他 登录授权；
- 支持 unionid（针对 QQ / 微信等）：如果开发者拥有多个移动应用、网站应用和公众帐号，可通过获取用户基本信息中的 unionid 来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号，用户的 unionid 是唯一的。
用户表设计
1. 用户主表 users
id
int
PRI
no
用户唯一索引
用户表主要用于存储用户信息，以及手机号登录认证。
2. 第三方用户信息表 oauths
id
int
PRI
no
唯一索引
用于存储第三方登录用户授权后的信息。
3. 扩展用户表信息 users_extends
对于用户表中没有维护的数据例如生日
brithday 、等级 level 等信息可以存储在当前信息表。使用场景
场景一： 先使用手机号注册，之后绑定微信、微博、QQ 等第三方账号；
注册成功后 users 表：
用户昵称及头像可在注册时要求添加也可自动生成。
之后根据用户 id 绑定 / 解绑 / 更换绑定相应第三方账号 QQ、微博、微信等账号
场景二：先使用微信、微博、QQ 等第三方账号注册，之后再绑定手机及其他未绑定第三方账号；
以微信登录为例，第一次绑定成功后，users 和 oauths。
通过第三方授权获取的用户信息 (昵称、头像) 创建 users 数据：
根据用户 ID 及第三方授权获得的信息创建 oauths 数据
其中微信登录可分为
wechat 微信移动应用，official_account 微信公众账号，mini_program 微信小程序，同一主体的情况下 unionid 是一致的。之后再根据用户 ID 绑定手机及其他未绑定第三方账号。
优缺点
优点：
- 可扩展；
- 易维护；
- 用户表简洁明了；
缺点：
会产生一个人有多个账号的情况。
例如：当用户用手机号注册后，退出登录，再使用微信授权登录就会产生 2 个 users 数据（反之亦然），但是本质来说是一个用户。
解决方法：
- 当用户第一次使用微信授权绑定的之后，弹出绑定手机页（可跳过，不强制绑定），如果手机号已经存在则告诉用户，“该手机号以存在，无法绑定”。
- 当用户使用手机号直接注册的账户登录后，授权绑定上述微信时提示用户 “此账号已存在绑定”； 有时候适当的冲突是无法避免的，可以使用友好的设计与话语增加用户体验。
Todo
- users_extends 表的使用举例。
- 会员系统
本作品采用