业务设计

菜单设计

关于菜单设计

菜单DDL

-- ----------------------------
-- Table structure for menus
-- ----------------------------
DROP TABLE IF EXISTS `menus`;
CREATE TABLE `menus`  (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '菜单id',
  `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '菜单名称',
  `path` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '菜单路由(路径)',
  `icon` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '菜单图标',
  `parent_id` int(11) NULL DEFAULT 0 COMMENT '菜单父级id',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 5 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci COMMENT = '菜单表' ROW_FORMAT = Compact;

在auth项目中，权限的细粒度是完全可以基于接口上的，通常来说，我们每当创建一个菜单的时候，就会至少有增删改查四个接口，这个完全是可以在新增菜单的时候将权限生成到数据库中，以避免在创建菜单后再去创建权限数据。

关于用户-角色-权限表的设计看：

因为生成一个菜单需要生成四个菜单，能不能设计出一对一的呢？

可以根据linux的文件夹数字赋权设计

对每个菜单设计出一个数字：

只要大于0，就一定有查看功能。毕竟没有查看功能却能增删改显得很奇怪。

数字	二进制	删除	修改	增加	描述
0	000	0	0	0	代表没有任何权限
1	001	0	0	1	只有增加权限
2	010	0	1	0	只有修改权限
3	011	0	1	1	只有增加和修改权限
4	100	1	0	0	只有删除权限
5	101	1	0	1	只有增加和删除权限
6	110	1	1	0	只有删除和修改权限
7	111	1	1	1	拥有增、删、改权限

可能还会有导出、暂停、禁用、下线或者其他权限，可以通过向前补一位数或者手动在权限表添加。补一位数也不影响之前的数字配置。

自增序列和自定义传唯一key哪个好？

为什么要把这个问题放在菜单设计里提问呢？

假如说，我们的菜单时设置自增id的，那么在权限中怎么关联菜单表呢？在上一个设计中，是不应该进行关联的，应该是直接在用户-权限表中设置关联，例如：zhangsan --> user:7。代表张三有增删改用户的权限。这时候的“user:7”是在权限表中看不到的。

假如用户需要自定义一个权限，例如在权限表中加入“export-->导出”，这时候给张三赋权，那么用户-权限表中结果就是：zhangsan --> export。

那么问题来了，如果管理员对user或者export进行修改呢？是不是意味着所有相关的表都要进行更新呢？这样id的优势就体现出来了，因为id对用户是隐藏的，是不会被变更的。

如果说统一全部换成了id，user的id是32，export的id也是32，并且不是在一张表的，那么张三的权限如下了。

username	authority
zhangsan	32:7
zhangsan	32

看起来似乎非常不直观，代码中也需要通过冒号区分是菜单权限还是自定义权限。