服务端业务设计方案——用户系统

这几年来不停在写需求，终于不想再闷头写业务了。希望记录下来一些自己验证过觉得蛮不错的方案，作为自己的沉淀，也方便大家一起交流，让这些方案更健壮和完善。

表结构

用户表

create table if not exists user
(
    id bigint auto_increment primary key,
    nickname varchar(255) default '' not null comment '用户昵称',
    d_flag tinyint default '0' not null comment '1已删除',
    c_time datetime not null comment '本数据创建时间',
    m_time datetime not null comment '最后修改的时间',
    constraint user_id_uindex unique (id)
)
comment '用户信息表'
;

该表可以增加更多字段，这取决于不同项目需要给用户记录的信息，或者需要给用户添加的标识，如角色等。用户更多的信息也可以存到别的表，与此表做关联，这个表一行记录代表一个用户。

用户的账号表

create table if not exists user_account
(
    id bigint auto_increment primary key,
    uid bigint unsigned default '0' not null comment '本登录方式所属用户id',
    type tinyint default '0' not null comment '账号类型：1-账号；2-微信开放平台unionid；3-openid；4-手机号；5-email；其它可自定义',
    account varchar(32) default '' not null comment '账号（如果是openid/unionid等第三方唯一串，则存到这）',
    pwd varchar(255) default '' not null comment '密码',
    d_flag tinyint default '0' not null comment '1已删除',
    c_time datetime not null comment '本数据创建时间',
    m_time datetime not null comment '最后修改的时间',
    constraint user_login_pwd_d_flag_type_account_uindex unique (d_flag, type, account),
    constraint user_login_pwd_id_uindex unique (id)
)
comment '用户的登录方式'
;

优点

1. 基本上每个项目都允许用户有多种登录方式，以前的方式是把用户的账号密码写在用户表，但是扩展性不强，而且不同登录方式有不同的字段名，对于封装业务组件不方便。

不足

1. 每个用户也就只有一个登录密码（使用账号、手机号、email登录时，密码是一样的），这里好像每个用户可以设置不同密码

因为仅仅为了一个密码就增加一个表，有点太浪费，每多一个表就多增加不少逻辑，除非你的业务里除了登录密码还有别的密码要保存。其实这种设计中，只要登录密码统一拿type=1的记录即可。

业务逻辑

登录接口入参定义

参数名	必须	类型	默认值	说明
type	是	int	默认：null 最小：1 最大：5	账号类型 1-传统账号； 2-app拿到的微信登录code； 3-小程序拿到的微信登录code； 4-手机号； 5-email； 其它可自定义
account	是	string	默认：null 最小：0B 最大：32B	账号 手机号、微信登录code也是通过这个字段传入
pwd	否	string	默认：null 最小：1 最大：32B	密码
smscode	否	string	默认：null 最小：1B 最大：10B	短信验证码
ua	否	string	默认："" 最小：0B 最大：255B	登录设备的信息 浏览器端是ua信息，app和小程序端则设备品牌_设备型号_操作系统版本_客户端平台
client	是	int	默认：null 最小：1 最大：5	客户端类型 用于区分同一个用户在哪些客户端上登录，把在相同客户端登录的用户挤掉线 只能填以下值：1小程序，2iOS，3Android，4pc端

登录逻辑

pc. 绿色是可选流程，可以选择跳过。

特别注意：这里存入session的只有uid，或者其它对于用户来说不会改变的id。

在我以前接触的一些设计来说，一般还会把用户昵称等基础信息存到session，我也这么做了好几年，但是最近发现

待完善。。。

特殊情况

因为不可能所有的需求都是一样的，总是会出现或多或少的特殊性，否则一套方案走天下，以后就不需要程序员了。

这里会列出一些这套方案能兼容的一些特殊情况，如果想到了不能兼容的情况，也会列出来

这是文章最底部