吐槽公司的后台权限架构

[gaicitadie]

菜单名称 菜单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码里面扒拉。。。

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

[dreampuf]

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

[rebornix]

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

[mengzhuo]

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

[gaicitadie]

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

[towser]

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

[thankyourtender]

掉坑里面了

[gaicitadie]

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

[GTim]

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

[gaicitadie]

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

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

[xds2000]

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

[GTim]

@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]

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

[gaicitadie]

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

[pynix]

楼主头像很萌

[ksc010]

可以同时用