这是一个创建于 4224 天前的主题，其中的信息可能已经有所发展或是发生改变。
菜单名称 菜单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 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功能了，幸好缓存方案被我否决了，再加上缓存，要饶死了。
 | 1 dreampuf 2014-04-18 12:38:27 +08:00 参考Linux 文件系统设计到了开头，发现太复杂设计不下去就甩锅了 |
 | 2 rebornix 2014-04-18 12:41:00 +08:00 *inx可以用数字设置文件权限，我想这位设计的朋友一定领悟了其中的风采 |
 | 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，你只能用树来载到内存里用了。 |
 | 4 gaicitadie OP @mengzhuo 就是这么搞得，用一个二维数组存放菜单树。展现还好，循环二维数组就可以了。排序累煞我也，如果有parent_id，直接一条sql语句就可以查出上一个菜单项和下一个菜单项。没有parent_id，只能用算法再从菜单树里寻找上一个和下一个菜单项，相关函数用了60行代码，一上午的工作量+中饭时间 |
 | 5 towser 2014-04-18 22:23:12 +08:00 parent_id性能不太好，不过一般菜单也没多到需要考虑性能。 |
 | 6 thankyourtender 2014-0-18 22:48:25 +08:00 掉坑里面了 |
| 7 gaicitadie OP @towser 那只是个后台啊，每天只有公司几个员工进去操作几下。还让我用缓存。。。 |
 | 8 yemoluo 2014-04-19 00:23:31 +08:00 话说除了权限感觉不好看外没发现有啥不好的... 如果需要权限只要％10得到数字进行判断，如果要父id则直接根据前3位直接拼装，或者/1000取整＊1000得到父id |
| 9 gaicitadie OP @GTim 排序不如用parent_id方便，上移、下移操作用parent_id的话只需要 select * from Table where ... and parent_id=xxx order by order_number 来获取上一个或下一个的order_number。而现在的情况就有些复杂了，一级菜单和二级菜单的排序需要拼装不同的sql。 如果情况再多变一些，出现3级菜单的需求，这个架构基本上就得推倒重来了 |
 | 10 xds2000 2014-04-19 04:44:14 +08:00 @gaicitadie 楼主可以给介绍一下MPTT |
| 11 yemoluo 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就会更多了 |
 | 12 griffinqiu 2014-04-19 10:01:29 +08:00 via iPhone 两套结构各有利弊，楼主太矫情 |
| 13 gaicitadie OP @GTim 你说的那种情况不存在，再大的菜单不可能因一个paren_id就把数据库撑爆，就算parent_id有几g，那么数据库本身可能得有几万个T了，如果缓存起来，有parent_id一样可以缓存起来 |
 | 14 pynix 2014-04-19 12:50:46 +08:00 via Android 楼主头像很萌 |
 | 15 ksc010 2014-04-20 12:39:40 +08:00 可以同时用 |
Select Language