可扩展的用户表设计

用户表结构的设计,算是整个应用架构的基石。如果基石不稳,待到后面需求跟进了发现不能应付,回过头来反复修改用户表,要大大小小作改动的地方也不少,甚至有些情况下无从下手,因此我们应该怎么设计用户表呢?

需求分析

  1. 多种登录方式:包括手机号、微信、QQ、微博等;
  2. 可进行绑定和解绑或者更换绑定:用户使用任意方式登录后可绑定和解绑或者更换绑定其他 登录授权;
  3. 支持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 wechat o2sck0XXXXXXR-NDA osssck0XXXXXXR-NDA null

其中微信登录可分为wechat 微信移动应用,official_account 微信公众账号,mini_program 微信小程序,同一主体的情况下unionid是一致的。

之后再根据用户ID绑定手机及其他未绑定第三方账号。

优缺点

优点

  • 可扩展;
  • 易维护;
  • 用户表简洁明了;

缺点
会产生一个人有多个账号的情况。
例如:当用户用手机号注册后,退出登录,再使用微信授权登录就会产生2个users数据(反之亦然),但是本质来说是一个用户。
解决方法:

  1. 当用户第一次使用微信授权绑定的之后,弹出绑定手机页(可跳过,不强制绑定),如果手机号已经存在则告诉用户,“该手机号以存在,无法绑定”。
  2. 当用户使用手机号直接注册的账户登录后,授权绑定上述微信时提示用户“此账号已存在绑定”;
    有时候适当的冲突是无法避免的,可以使用友好的设计与话语增加用户体验。

Todo

  • users_extends表的使用举例。
  • 会员系统
本作品采用《CC 协议》,转载必须注明作者和本文链接
本帖由系统于 1年前 自动加精
franktrue
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 10

最近我也刚刚做了类似的事情,不过我的做法和你有点不一样,针对不同的登录终端我都会有一个对应的用户表例如 wechat_official_accounts, wechat_mini_program_accounts, h5_mobile_accounts,同时我也设计了一个登录无关的用户表叫biz_users,里面使用了morphTo()来关联不同的实际登录表,同样的针对不同的登录来源有不同的登录controller负责,一旦登录完成在session中存储的都是BizUser实体,这样在后续的业务操作中我不需要考虑登录来源所有的业务操作都围绕BizUser,就算以后要添加登录方式,也非常简单了。

1年前 评论
franktrue

@Handle 原理上其实差不都,我是使用oauths表来对应你的多个用户表的,不过你那样写的话确实职责更明确,我的想法是直接一个登陆注册逻辑然后都遵循一个规则,你的是各论各的,互不影响,很赞

1年前 评论

换个方式

小项目的话,用户的主信息字段是固定的,不固定增减多也影响不大。
大项目的话,用户的主信息字段是固定的,不怎么增减,如果增减频繁,换个产品经理就是了。

oauth 这一块,目前也就这么几家,短期之内要多几个不容易,全部写在表里更简单。
至于国外的那些个,我想先解决 GFW 再说吧。

user_extends 看似简单,但一个用户有10项个人资料就要写入10行,表行数暴增不说,取出后再处理10遍也是够够的了,话说一个用户10项个人资料不算多吧?

一是真有这么多扩展吗?
二是考虑这么多的扩展,用 NoSQL 不好吗?用 MongoDB 之类的文档数据库不行吗?干吗非要往关系型数据库上堆呢?

个人意见。

1年前 评论

@qufo 这是一个系统规模的问题。

1年前 评论
黑将军

@Handle 我也是用同样的方式,不过我不是用多个controller处理不同的登录终端,只请求头里加个字段区分而已

1年前 评论
JohnYep

学习了

1年前 评论

@Handle 能晒出具体表结构吗?感觉这样的设计还是比较好

1年前 评论

@cboy868
---------------------DDL-------------------
create table biz_users
(
id serial not null
constraint biz_users_pkey
primary key,
user_id integer not null,
user_type varchar(255) not null,
deleted_at timestamp(0),
created_at timestamp(0),
updated_at timestamp(0)
)
;

create table wechat_mini_program_accounts
(
id serial not null
constraint wechat_users_pkey
primary key,
open_id varchar(255) not null
constraint wechat_users_open_id_unique
unique,
deleted_at timestamp(0),
created_at timestamp(0),
updated_at timestamp(0),
name varchar(255),
avatar varchar(255)
)
;

create table wechat_official_accounts
(
id serial not null
constraint wechat_official_accounts_pkey
primary key,
open_id varchar(255) not null
constraint wechat_official_accounts_open_id_unique
unique,
name varchar(255),
avatar varchar(255),
is_valid boolean default true not null,
unionid varchar(255),
is_preview_user boolean default false not null,
created_at timestamp(0),
updated_at timestamp(0),
deleted_at timestamp(0)
)
;
---------------------DDL-------------------

class BizUser extends Model
{
use SoftDeletes;
protected $guarded = ['id'];
public function user()
{
return $this->morphTo();
}
}

1年前 评论

把手机号和密码,直接放到oauths中,是不是更好点呢,用户表只存基准数据,不做登录相关的处理

1年前 评论
franktrue

@大业 也是可以的,我这边主要是把手机号密码登陆作为主要登陆场景,所以这么操作啦

1年前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!