服务端业务设计方案——用户系统表结构业务逻辑
这几年来不停在写需求，终于不想再闷头写业务了。希望记录下来一些自己验证过觉得蛮不错的方案，作为自己的沉淀，也方便大家一起交流，让这些方案更健壮和完善。
表结构
用户表
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即可。
本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录