吐槽公司的后台权限架构

2014-04-18 12:07:47 +08:00
 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码里面扒拉。。。
5186 次点击
所在节点    程序员
15 条回复
dreampuf
2014-04-18 12:38:27 +08:00
参考Linux 文件系统设计到了开头,发现太复杂设计不下去就甩锅了
rebornix
2014-04-18 12:41:00 +08:00
*inx可以用数字设置文件权限,我想这位设计的朋友一定领悟了其中的风采
mengzhuo
2014-04-18 12:52:37 +08:00
邮编转地区的设计方案?
------------------------------------------------------
2、4、6、8表示(浏览、修改、添加、删除)
Linux是用二进制的位来决定啊,这设计算个山寨货
1 = 1 可执行
2 = 10 可写
4 = 100 可读
所以 7 = 111 (可读、写、执行)
-------------------------------------------------------
因为没有parent_id,你只能用树来载到内存里用了。
gaicitadie
2014-04-18 13:05:44 +08:00
@mengzhuo 就是这么搞得,用一个二维数组存放菜单树。展现还好,循环二维数组就可以了。排序累煞我也,如果有parent_id,直接一条sql语句就可以查出上一个菜单项和下一个菜单项。没有parent_id,只能用算法再从菜单树里寻找上一个和下一个菜单项,相关函数用了60行代码,一上午的工作量+中饭时间
towser
2014-04-18 22:23:12 +08:00
parent_id性能不太好,不过一般菜单也没多到需要考虑性能。
thankyourtender
2014-04-18 22:48:25 +08:00
掉坑里面了
gaicitadie
2014-04-18 23:10:50 +08:00
@towser 那只是个后台啊,每天只有公司几个员工进去操作几下。还让我用缓存。。。
GTim
2014-04-19 00:23:31 +08:00
话说除了权限感觉不好看外没发现有啥不好的... 如果需要权限只要%10得到数字进行判断,如果要父id则直接根据前3位直接拼装,或者/1000取整*1000得到父id
gaicitadie
2014-04-19 00:43:45 +08:00
@GTim 排序不如用parent_id方便,上移、下移操作用parent_id的话只需要 select * from Table where ... and parent_id=xxx order by order_number 来获取上一个或下一个的order_number。而现在的情况就有些复杂了,一级菜单和二级菜单的排序需要拼装不同的sql。

如果情况再多变一些,出现3级菜单的需求,这个架构基本上就得推倒重来了
xds2000
2014-04-19 04:44:14 +08:00
@gaicitadie 楼主可以给介绍一下MPTT
GTim
2014-04-19 08:20:29 +08:00
@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
2014-04-19 10:01:29 +08:00
两套结构各有利弊,楼主太矫情
gaicitadie
2014-04-19 11:54:47 +08:00
@GTim 你说的那种情况不存在,再大的菜单不可能因一个paren_id就把数据库撑爆,就算parent_id有几g,那么数据库本身可能得有几万个T了,如果缓存起来,有parent_id一样可以缓存起来
pynix
2014-04-19 12:50:46 +08:00
楼主头像很萌
ksc010
2014-04-20 12:39:40 +08:00
可以同时用

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/109074

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX