权限表设计

---

author: wangsu20M

权限表需要有需求，感觉无法做出一个十全十美的权限设计。
传统的管理系统中一般需要一下的内容：机构、用户、岗位、角色、资源（菜单、按钮）。
而现在的互联网中，对于登陆的处理又有不同。首先可能会将管理员与普通用户划分为不同系统，也有可能消除了机构的划分，取而代之的是用户类型的划分。所以只对用户登陆表进行简单猜想。

传统管理系统

机构表：

create table sys_organization (
  id char(32) primary key comment '主键标志',
  o_name varchar (100) not null comment '机构名称',
  o_parent char(32) not null comment '父节点'
) comment '组织机构树' ;

用户信息表：

CREATE TABLE sys_user (
  id CHAR(32) PRIMARY KEY,
  organization_id CHAR(32) NOT NULL COMMENT '用户所属机构',
  user_name VARCHAR (100) NOT NULL COMMENT '用户姓名',
  upassword VARCHAR (100) NOT NULL COMMENT '用户密码',
  user_mobile CHAR(11) NOT NULL COMMENT '用户电话号',
  user_identity VARCHAR (30) COMMENT '身份证号',
  user_email VARCHAR (50) COMMENT '邮箱地址'
) COMMENT '用户信息表' ;

岗位表：

CREATE TABLE sys_postation (
  id CHAR(32) PRIMARY KEY,
  pos_name VARCHAR (100) NOT NULL COMMENT '岗位名称',
  pos_describe VARCHAR (200) COMMENT '岗位描述'
) COMMENT '岗位信息表' ;

用户岗位表：

create table user_pos (
  id char(32) primary key,
  pos_id char (32) not null comment '岗位id',
  user_id varchar (200) comment '用户id'
) comment '岗位用户表' ;

角色表：

CREATE TABLE sys_role (
  id CHAR(32) PRIMARY KEY,
  role_name VARCHAR (100) NOT NULL COMMENT '角色名称',
  role_describe VARCHAR (200) COMMENT '角色描述'
) COMMENT '角色表' ;

菜单资源表：

CREATE TABLE sys_menu_resources (
  id CHAR(32) PRIMARY KEY,
  menu_name VARCHAR (100) NOT NULL COMMENT '菜单名称',
  menu_url VARCHAR (200) COMMENT '菜单地址',
  parent_id CHAR(32) COMMENT '父节点id'
) COMMENT '菜单资源表' ;

按钮资源表：

CREATE TABLE sys_btn_resources (
  id CHAR(32) PRIMARY KEY,
  btn_code VARCHAR (10) COMMENT '按钮编码（用于界面配置）',
  btn_name VARCHAR (100) NOT NULL COMMENT '菜单名称',
  menu_id VARCHAR (200) COMMENT '属于哪个菜单资源',
) COMMENT '按钮资源表' ;

资源角色对应表：

CREATE TABLE role_resources (
  id CHAR(32) PRIMARY KEY,
  role_id CHAR (32) COMMENT '角色id',
  menu_id CHAR(32) NOT NULL COMMENT '菜单id',
  menu_parent_id CHAR(32) NOT NULL COMMENT '菜单父节点id，默认为32个f',
  btn_id CHAR(32) NOT NULL COMMENT '按钮id'
) COMMENT '角色资源对应表' ;

多方式用户登陆表设计

现状：当前可见的用户注册方式有手机号注册、邮箱注册、第三方（微信、QQ号）注册。当用户注册成功后又有可能会增加其他的登陆方式。所以将用户认证与用户信息拆分为不同的表很有必要。那么统一叫法，有关登陆叫用户，有关人员信息叫做操作人员。
当需要存在其他方式登陆时，设计如下表，包括操作人员表、手机号验证码表（用户）、oauth验证相关（用户）的表。
将认证表与信息表拆分开来，带来的问题是多个用户信息绑定同一操作人员。
操作人员表：

CREATE TABLE sys_operator (
  id CHAR(32) PRIMARY KEY,
  organization_id CHAR(32) NOT NULL COMMENT '操作人员所属机构',
  user_name VARCHAR (100) NOT NULL COMMENT '操作人员姓名',
  user_mobile CHAR(11) NOT NULL COMMENT '操作人员电话号',
  user_identity VARCHAR (30) COMMENT '操作人员身份证号',
  user_email VARCHAR (50) COMMENT '操作人员邮箱地址'
) COMMENT '操作人员表' ;

手机号验证码表：该表可以直接使用redis去实现存储

CREATE TABLE phone_verify (
  id CHAR(32) PRIMARY KEY,
  operator_id CHAR(32) COMMENT '操作人员id',
  mobile CHAR(11) NOT NULL COMMENT '手机号',
  verify_code VARCHAR (10) NOT NULL COMMENT '验证码',
  send_time DATETIME COMMENT '验证码发送时间'
) COMMENT '手机验证码' ;

oauth验证相关表与手机验证码表类似，当添加不同类型的登陆方式时，可以添加不同类型的表，可以添加字段区分。

CREATE TABLE oauth_user (
  id CHAR(32) PRIMARY KEY,
  oauth_type VARCHAR (20) COMMENT '类型：qq、微信',
  operator_id CHAR(32) COMMENT '操作人员id',
  verify_id CHAR(100) NOT NULL COMMENT '其他账号标志',
  token_code VARCHAR (10) NOT NULL COMMENT 'token',
  send_time DATETIME COMMENT '验证时间等'
) COMMENT '手机验证码' ;