吐槽公司的后台权限架构

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 4435 days ago, the information mentioned may be changed or developed.

菜单名称菜单code码

一级菜单1 100000
—— 二级菜单1 100110
—— 二级菜单2 100120
一级菜单2 200000
—— 二级菜单1 200110
—— 二级菜单2 200120

设计成这样的数据库，用code码确定一级菜单和二级菜单的从属关系比如100110和100120从属100000。不让用parent_id，说是为了性能考虑。

所有菜单的code码最后一位是0，某个用户对某个菜单的操作权限依次用 2、4、6、8表示(浏览、修改、添加、删除)，比如一个用户对100120有修改权限，则为100124(100120+4)，用这种数字来判断权限，说是为了性能考虑。

说是为了性能，还让我用缓存技术，把菜单数据都缓存到memcached里面，尼玛，还嫌累不死我吗。你设计数据库倒是方便，设计成这鸟样考虑过我写代码的感受吗，因为没有parent_id，进行排序上移下移操作的时候我只能从code码里面扒拉。。。

Supplement 1 · Apr 18, 2014

这位负责人是从php的文件数据库时代走过来的，菜单的层级关系不用parent_id，用100000,100110,100120表示，我几乎要用php来实现部分sql功能了，幸好缓存方案被我否决了，再加上缓存，要饶死了。

菜单

Code

15 replies • 1970-01-01 08:00:00 +08:00

dreampuf

Apr 18, 2014

参考Linux 文件系统设计到了开头，发现太复杂设计不下去就甩锅了

rebornix

Apr 18, 2014

*inx可以用数字设置文件权限，我想这位设计的朋友一定领悟了其中的风采

mengzhuo

Apr 18, 2014

邮编转地区的设计方案？
------------------------------------------------------
2、4、6、8表示(浏览、修改、添加、删除)
Linux是用二进制的位来决定啊，这设计算个山寨货
1 = 1 可执行
2 = 10 可写
4 = 100 可读
所以 7 = 111 （可读、写、执行）
-------------------------------------------------------
因为没有parent_id，你只能用树来载到内存里用了。

gaicitadie

Apr 18, 2014

@mengzhuo 就是这么搞得，用一个二维数组存放菜单树。展现还好，循环二维数组就可以了。排序累煞我也，如果有parent_id，直接一条sql语句就可以查出上一个菜单项和下一个菜单项。没有parent_id，只能用算法再从菜单树里寻找上一个和下一个菜单项，相关函数用了60行代码，一上午的工作量+中饭时间

towser

Apr 18, 2014

parent_id性能不太好，不过一般菜单也没多到需要考虑性能。

thankyourtender

Apr 18, 2014

掉坑里面了

gaicitadie

Apr 18, 2014

@towser 那只是个后台啊，每天只有公司几个员工进去操作几下。还让我用缓存。。。

yemoluo

Apr 19, 2014

话说除了权限感觉不好看外没发现有啥不好的... 如果需要权限只要％10得到数字进行判断，如果要父id则直接根据前3位直接拼装，或者/1000取整＊1000得到父id

gaicitadie

Apr 19, 2014

@GTim 排序不如用parent_id方便，上移、下移操作用parent_id的话只需要 select * from Table where ... and parent_id=xxx order by order_number 来获取上一个或下一个的order_number。而现在的情况就有些复杂了，一级菜单和二级菜单的排序需要拼装不同的sql。

如果情况再多变一些，出现3级菜单的需求，这个架构基本上就得推倒重来了

xds2000

Apr 19, 2014

@gaicitadie 楼主可以给介绍一下MPTT

yemoluo

Apr 19, 2014

@gaicitadie 如果要3级菜单的确不好用，但可以在通过：(%10000)+(／10000＊100000)来调整位数，达到前2位表示1级中间2位表示2级，最后三位维持愿意不变。

如果根据parent_id来选择上一个和下一个菜单，可以直接先计算parent_id=int(id%10000)*10000
然后where的时候只要:>parent_id and < parent_id + 100000

因为后台菜单不会太多，为了不2次查询，直接select all出来然后foreach即可.缓存的话，就更不用说了.一个缓存保存顶级菜单id，剩下的缓存根据每个顶级菜单id保存次级菜单id

还好这里没有根据树来保存，不然你可能要哭了.

菜单问题，很久之前就有2套通俗的解决方案，选择只是个人偏爱和熟练度. 小公司数据库没有那么多诡异的需求，但大公司数据库，能不加字段是坚决不加字段的.加一个parent_id 说不定就造成了好几g的数据对于磁盘上的每个page页，获取到的数据就更少了，那么磁盘io就会更多了

griffinqiu

Apr 19, 2014 via iPhone

两套结构各有利弊，楼主太矫情

gaicitadie

Apr 19, 2014 via Android

@GTim 你说的那种情况不存在，再大的菜单不可能因一个paren_id就把数据库撑爆，就算parent_id有几g，那么数据库本身可能得有几万个T了，如果缓存起来，有parent_id一样可以缓存起来

pynix

Apr 19, 2014 via Android

楼主头像很萌

ksc010

Apr 20, 2014

可以同时用