服務端業務設計方案——用戶系統

這幾年來不停在寫需求，終於不想再悶頭寫業務了。但願記錄下來一些本身驗證過以爲蠻不錯的方案，做爲本身的沉澱，也方便你們一塊兒交流，讓這些方案更健壯和完善。

表結構

用戶表

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便可。

業務邏輯

待完善。。。