用户基础信息表 users 用户授权信息表 user_auths
id id
nickname user_id
avatar identity_type 登录类型 (手机号/邮箱/用户名) 或第三方应用名称 (微信 , 微博等)
. identifier 标识 (手机号/邮箱/用户名或第三方应用的唯一标识)
. credential 密码凭证 (站内的保存密码 , 站外的不保存或保存 token)

优缺点

  • 一. 站内登录类型无限拓展 , 代码改动小 ; 如果真要支持身份证登录了 , 只要少许几处改动 , 无需修改表结构 ;

  • 二. 第三方登录类型可用工场模式批量拓展 , 新增第三方登录类型的开发成本降到最低 ;
    原来条件下 , 应用需要验证手机号是否已验证和邮箱是否已验证 , 需要相对应多一个字段如 phone_verified 和 email_verified , 如今只要在 user_auths 表中增加一个统一的 verified 字段 , 每种登录方式都可以直观看到是否已验证情况 ; 基于信任第三方登录的数据准确性 , 默认第三方登录都是已验证 ; 如果用户修改登录手机号或登录邮箱 , 也能清晰跟踪每一步的完成度 ;

  • 三. 可按需绑定任意数量的同类型登录方式 , 即一个用户可以绑定多个微信 , 可以有多个邮箱 , 可以有多个手机号 , 是不是很赞 ? 当然你也可以限制一种登录方式只有一条记录 ;

  • 四. 在 user_auths 添加相应的时间和 IP 地址 , 就可以更加完整地跟踪用户的使用习惯 , 比如 , 已经不使用微博登录两年多 , 已经绑定微信 300 天

  • 五. 即使完全使用第三方帐号登录 , 可在前端做到 “无需注册本站帐号” 的效果 ; 过去许多网站虽然支持第三方帐号登录 , 但出于留存用户等原因 , 第一次微博登录回来 , 让你再填写一套他们网站的邮箱 , 密码等信息 , 也就失去了微博登录的最大意义 ; 从技术上说 , 原有的结构导致除了在微博用户表建立一个条目外 , 必须在用户表建立一条对应的条目 , 而且一般情况下不能让用户表里的邮箱或者用户名和密码留空 ; 用户体验好的 , 邮箱自动生成微博ID@id.weibo.sina.com , 密码则随机生成 ; 至于体验不好的 , 只能说早知道还不如不用微博登录呢 ! 现在呢 , 我们的这个用户表结构则完全没有这样的困扰 , 只要微博提供的昵称和头像地址就可以生成这个用户 , 再关联他的微博登录记录 ; 而且我们的表结构意味着 , 用户可以解除他的所有登录方式 , 于是这个账户变彻底变成了没法登录的僵尸 (解决办法是在代码里加一个限制 , 至少保留一条user_auths的记录) ; 如果你非得得到用户的邮箱 , 那么每次登录的时候看到他不存在一条 identify_type 为 email 的记录 , 则弹窗弹死他 , 让他赶快填邮箱 , 否则啥都别干 ;

  • 六. 提升了逻辑思维能力 , 抽象出事物本质是码农必备职业素养 , 通过对用户表结构的学习研究 , 提高了鄙人的各方面技能 , 从此写代码一路顺风顺水…

  • 七. 如果你说邮箱和手机号就是用户信息的组成部分 , 他们依然需要体现在 users 表中作为前端展示?没问题 , users 表尽管拓展 , users 表里依然有email , phone , 但他们仅仅作为 “展示用途” , 和昵称 , 头像 , 或者性别这些属性没有本质区别 ; 在用户信息表与用户授权登录拆分后 , 用户信息表可以随时增加任意字段 , 加星座 , 加生日 , 都没问题 , 只需要在前端展示时多几个输入框 , 录入时多几行代码 , 与用户登录相关的问题做到最大程度解耦 ;

  • 一. 原先的用户判断由 1 次 SQL 变成 2 次 SQL 请求 ;

  • 二. 用户同时存在邮箱 , 用户名 , 手机号等多种站内登录方式时 , 改密码时必须一起改 , 否则就变成了 邮箱 + 新密码 , 手机号 + 旧密码 访问了 , 肯定是很诡异的情况 ; 如果考虑到这一点 , 又要在 user_auths 表中新增一个表示站内登录方式或第三方登录方式的标识字段 ;

  • 三. 代码量增加了 , 有些情况下逻辑判断增加了 , 难度增大了 ; 举个例子 , 无论用户是否已登录 , 无论用户是否已注册过 , 都是点击同一链接前往微博第三方授权后返回 , 可能出现几种情况 : 1 , 该微博在本站未注册过 , 很好 , 直接给他注册关联并登录;2 , 该微博已经在本站存在 , 当前用户未登录 , 直接登录成功;3 , 该微博未在本站注册 , 但当前用户已经登录并关联的是另一个微博帐号 , 作何处理取决于是否允许绑定多个微博帐号;4 , 该微博未在本站注册过 , 当前用户已登录 , 尝试进行绑定操作;5 , 该微博已经注册 , 用户又已使用该帐号登录 , 为何他重复绑定自己 ; 6 , 该微博已经在本站存在 , 但当前用户已经登录并关联的是另一个微博帐号 , 作何处理 ? 切换用户或是报错 ? (画一个流程图能更好描述这个问题) 这个问题与采用的数据结构没有关系 , 只是在做第三方帐号注册登录时遇到的各种情况 , 在此一并整理 ;

参考/转载:https://blog.csdn.net/tojohnonly/article/details/78189748