项目从无到有，两个月了。一期完成。

权限目前还很简单。USER表，ROLE表，RESOURCE表三个。

目前只有两个商铺。id是0的是我们自己，作为后台运维管理，也抽象成一个商铺，id为0。另一个商铺id为1,是我们第一家用户。

USER表有merchantId和type字段。merchantId表示这个User属于哪个商品。type字段表示用户类型。目前没什么用，因为merchantId就能区分，是商铺后台管理人员，还是我们自己的后天运维人员。以后如果商铺的销售员，配送员，这些身份的员工要登录后台的话，这个字段会有用，作为预留字段。

一个USER可以有多个ROLE。

ROLE表也有merchantId和type字段。同USER。一个ROLE可以访问多个RESOURCE。

RESOURCE表有type字段。表示这个RESOURCE是属于运维使用，还是商铺使用。

预置数据：

所有RESOURCE资源.包括一个特殊资源‘admin‘。表示只有管理员才能有资格访问的资源。用在分配权限操作上。

一个ROLE,code是admin。不属于任何商铺.merchantId为空。拥有RESOURCE：admin权限（这个权限不公布到界面上来进行选择）。

两个USER。一个是我们运维的admin,merchatId是0，一个是第一家商铺的admin，merchantId是1。他们都拥有那个预置Role的角色。

这样设计的好处，就是运维的admin和商铺的admin逻辑一样了。都只有一个分配权限的小权限范围。系统初始化后，在登录页面登录需要选择是运维还是商铺。各自有自己的User和admin。用各自的admin登录进去，就只有一个权限管理菜单。之后在新增User,分配其他业务权限。这样做就统一了。

B2B多商铺初期权限数据库设计