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

这几年来不停在写需求，终于不想再闷头写业务了。但愿记录下来一些本身验证过以为蛮不错的方案，做为本身的沉淀，也方便你们一块儿交流，让这些方案更健壮和完善。

表结构

用户表

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 '用户的登陆方式'
;

基本上每一个项目都容许用户有多种登陆方式，之前的方式是把用户的帐号密码写在用户表，可是扩展性不强，并且不一样登陆方式有不一样的字段名，对于封装业务组件不方便。

这样设计有个麻烦的地方，其实应该再增长一个密码表，由于每一个用户也就只有一个登陆密码，或者会有几个别的功能密码。可是这种设计也能兼容这两个状况，只要登陆密码统一拿type=1的记录，其它的功能密码，只要增长type便可。

业务逻辑

待完善。。。