浅谈第三方登录用户表结构设计方案
共 2138字，需浏览 5分钟
·
2021-02-06 12:37
用最朴实的语言，讲解最复杂的业务场景！
国民两大流量入口，大家不说也想到了，分别是微信和QQ。所以为了方便获取用户来源都对接了微信登录或者QQ登录，这一类型的第三方登录入口。今天就以对接微信登录、QQ登录与苹果登录。来说说对第三方用户体系与我方系统用户体系的对接的一些可行性方案。
0x01：我方用户表与第三方用户表同为一张表
一般系统都会有自己的一套用户系统，主管用户的注册、登录、登出、权限等。比如我方用户系统的用户表 t_user 大致包含如下一些字段：
id：主键id
username：用户名
age：用户年龄
mobile：手机号号码
password：登录密码
source_from：用户来源
auth_flag：用户认证状态
create_date：注册日期
以上是最简单的一些用户信息了，那现在要对接第三方用户体系。比如，对接微信。这是最普遍的第三方用户对接了。因为这种方案我方用户表与第三方用户表在一张表里，所以需要在用户表 t_user 中添加一个标识，表示我方用户与微信用户唯一绑定的字段，一般使用微信的 openid，这样的话需要修改表，添加一个wx_openid字段
id：主键id
username：用户名
age：用户年龄
mobile：手机号号码
password：登录密码
source_from：用户来源
auth_flag：用户认证状态
wx_openid：微信的openid
create_date：注册日期
如果有要对接 QQ 和 Apple，这样的话有的修改表：
id：主键id
username：用户名
age：用户年龄
mobile：手机号号码
password：登录密码
source_from：用户来源
auth_flag：用户认证状态
wx_openid：微信openid
qq_openid：qq openid
appleid：苹果id
create_date：注册日期
这种方案设计简单，只要对接一个第三方，就是需要对原来的用户表进行修改，如果对接的第三方过多，用户表就慢慢的变得非常臃肿。从另外一个方面看，对原来用户代码进行修改。
0x02：我方用户表一张表、第三方用户表一张表
由于第一种方案如果对接额外的第三方需要不断的修改用户，以及原来的代码逻辑，对生产可能造成不确定因素。所以可以采取另外一种方案我方用户表一张表、第三方用户表一张表这种方案。比如用户表 t_user 设计大致如下：
id：主键id
username：用户名
age：用户年龄
mobile：手机号号码
password：登录密码
source_from：用户来源
auth_flag：用户认证状态
create_date：注册日期
第三方用户表 t_third_acount 设计大致如下：
user_id：对应 t_user的用户id
third_unique_acount：第三方唯一用户id，可以是微信的openid，可以是QQ的openid，抑或苹果id
type：标识第三方类型，这里规定1.代表微信，2.代表QQ，3.代表苹果
bind_flag：标识是否绑定，1绑定，2解绑
create_date：绑定时间
这样设计的话，以后一般不需要修改表结构；但是新添加第三方用户对接时，还是免不了需要对原来的代码逻辑做改动。
0x03：我方用户表一张表、第三方用户表多张表
基于第二种方案，第三方用户表使用了一个 type 字段来表示不同的第三方用户体系，通过不断的新增不同的枚举来标识不同的第三方。所以可以去除这个字段，然后不同的第三方使用不同的表来标识。比如用户表 t_user 设计大致如下：
id：主键id
username：用户名
age：用户年龄
mobile：手机号号码
password：登录密码
source_from：用户来源
auth_flag：用户认证状态
create_date：注册日期
微信用户体系的表 t_wechat_acount 设计大致如下如下：
user_id：对应 t_user的用户id
wx_openid：微信的openid
bind_flag：标识是否绑定，1绑定，2解绑
create_date：绑定时间
QQ用户体系的表 t_qq_acount 设计大致如下如下：
user_id：对应 t_user的用户id
qq_openid：QQ的openid
bind_flag：标识是否绑定，1绑定，2解绑
create_date：绑定时间
苹果用户体系的表 t_apple_acount 设计大致如下如下：
user_id：对应 t_user的用户id
appleid：苹果id
bind_flag：标识是否绑定，1绑定，2解绑
create_date：绑定时间
这些方案的话，第三方用户表就有点膨胀的意思，系统对接了多少个第三方用户体系，就有多少张第三方用户体系表。
以上三种方案，属谁最优，不下定论。我觉得根据项目的要求，满足自身项目的需要，符合可用的业务场景的方案就是最优解。
喜欢，在看