上文介绍 如何设计一个可拓展的账号系统【一】，主要是关于主账号（邮箱、手机、用户名）。
接下来我们将介绍一下账号系统接入第三方登录的设计：
基本表
user 表还是作为基本的信息表存在：
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 用户id（主键） |
| nickname | varchar(20) | 昵称 |
| avatar | varchar(255) | 头像 |
| fullname | varchar(30) | 姓名 |
| introduction | varchar(255) | 个人简介 |
| birthday | int(11) | 生日 |
| ... | ... | ... |
这一次我们将增加新的表用于支持第三方登录
oauth_type 表
存储支持的第三方登录的类型，存储 wechat、qq 等标示
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 主键 |
| name | varchar(20) | 类型名 |
| descriptioin | varchar(255) | 类型描述 |
基础版 oauth 表
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | id（主键） |
| user_id | int(11) unsigned | 用户id |
| unionid | varchar(50) | 用户在各第三方平台的唯一id |
| openid | varchar(50) | 用户在各第三方平台下各应用的id |
| oauth_type | int(11) | 第三方登录标示 |
刚开始接触第三方登录的人可能不是很清楚 unionid 、openid 是什么，下面简单介绍一下:
-
unionid: 公司M在微信开发平台创建了应用A,B， 用户应用A, B授权登录后，会有一个统一的
unionid，通过对这个unionid的判断，我们可以判断是否是同一个用户。 -
openid: 公司M在微信开发平台创建了应用A,B， 用户应用A, B授权登录后，在A，B应用上会有不同的openid。在公司N上的应用C,D 得到会是另外的2个openid
通过以上的描述，一些同学大概知道 oauth_type, 基础版 oauth 存储的数据：
oauth_type 存储的数据
| id | name | description |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ...... | ...... |
oauth 存储的数据
| id | unionid | openid | oauth_type |
|---|---|---|---|
| 1 | aaaaaa | xxxxxx | 1 |
| 2 | aaaaaa | yyyyyy | 1 |
| 3 | aaaaaa | zzzzzz | 1 |
| 4 | bbbbbb | mmmmm | 1 |
| 5 | bbbbbb | nnnnnnnn | 2 |
| 5 | ...... | ...... | 2 |
事实上openid比较少用，基础版 oauth 还可以继续改造, 我们可以把 openid 移到另外一个表 oauth_platform，然后建立 unionid 与 openid 之间的联系
oauth_platform 表
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | id（主键） |
| oauth_id | int(11) | oauth 表的主键 id |
| openid | varchar(50) | ... |
| appid | varchar(32) | ... |
分析以上表设计的好处
按登录类型建表
如果大家有看过第一篇 如何设计一个可拓展的账号系统【一】， 就知道 basic_auth 表。
如果是普通的账号登录，查询的顺序是 basic_auth -> user
如果是第三方登录，查询的顺序是 oauth -> user，
显而易见，我们把第三方登录、账号登录区分开了，而不是塞在一个大表
不同类型的账号，一个用户id
basic_auth, oauth 虽然是不同的账号类型，但是可以通过 user 表 建立联系 ，oauth、basic_auth 上都会存储 user_id。可在产品设计上，达到 1个用户只有1个账号，降低多账号带来的差体验。
