V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
gaicitadie
V2EX  ›  程序员

吐槽公司的后台权限架构

  •  
  •   gaicitadie · 2014-04-18 12:07:47 +08:00 · 5171 次点击
    这是一个创建于 3853 天前的主题,其中的信息可能已经有所发展或是发生改变。
    菜单名称 菜单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码里面扒拉。。。
    第 1 条附言  ·  2014-04-18 12:59:06 +08:00
    这位负责人是从php的文件数据库时代走过来的,菜单的层级关系不用parent_id,用100000,100110,100120表示,我几乎要用php来实现部分sql功能了,幸好缓存方案被我否决了,再加上缓存,要饶死了。
    15 条回复    1970-01-01 08:00:00 +08:00
    dreampuf
        1
    dreampuf  
       2014-04-18 12:38:27 +08:00
    参考Linux 文件系统设计到了开头,发现太复杂设计不下去就甩锅了
    rebornix
        2
    rebornix  
       2014-04-18 12:41:00 +08:00
    *inx可以用数字设置文件权限,我想这位设计的朋友一定领悟了其中的风采
    mengzhuo
        3
    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
        4
    gaicitadie  
    OP
       2014-04-18 13:05:44 +08:00
    @mengzhuo 就是这么搞得,用一个二维数组存放菜单树。展现还好,循环二维数组就可以了。排序累煞我也,如果有parent_id,直接一条sql语句就可以查出上一个菜单项和下一个菜单项。没有parent_id,只能用算法再从菜单树里寻找上一个和下一个菜单项,相关函数用了60行代码,一上午的工作量+中饭时间
    towser
        5
    towser  
       2014-04-18 22:23:12 +08:00
    parent_id性能不太好,不过一般菜单也没多到需要考虑性能。
    thankyourtender
        6
    thankyourtender  
       2014-04-18 22:48:25 +08:00
    掉坑里面了
    gaicitadie
        7
    gaicitadie  
    OP
       2014-04-18 23:10:50 +08:00
    @towser 那只是个后台啊,每天只有公司几个员工进去操作几下。还让我用缓存。。。
    GTim
        8
    GTim  
       2014-04-19 00:23:31 +08:00
    话说除了权限感觉不好看外没发现有啥不好的... 如果需要权限只要%10得到数字进行判断,如果要父id则直接根据前3位直接拼装,或者/1000取整*1000得到父id
    gaicitadie
        9
    gaicitadie  
    OP
       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
        10
    xds2000  
       2014-04-19 04:44:14 +08:00
    @gaicitadie 楼主可以给介绍一下MPTT
    GTim
        11
    GTim  
       2014-04-19 08:20:29 +08:00   ❤️ 1
    @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
        12
    griffinqiu  
       2014-04-19 10:01:29 +08:00 via iPhone
    两套结构各有利弊,楼主太矫情
    gaicitadie
        13
    gaicitadie  
    OP
       2014-04-19 11:54:47 +08:00 via Android
    @GTim 你说的那种情况不存在,再大的菜单不可能因一个paren_id就把数据库撑爆,就算parent_id有几g,那么数据库本身可能得有几万个T了,如果缓存起来,有parent_id一样可以缓存起来
    pynix
        14
    pynix  
       2014-04-19 12:50:46 +08:00 via Android
    楼主头像很萌
    ksc010
        15
    ksc010  
       2014-04-20 12:39:40 +08:00
    可以同时用
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1168 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 18:26 · PVG 02:26 · LAX 10:26 · JFK 13:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.