在我们开发过程中经常会遇到各种组织树结构，比如我们的公司人员结构，权限资源的管理，等等。而我们这些数据落到表里面是以一条条数据构成的，我们存储资源时按照一条条存储是非常简单的，但是在操作资源构建树的时候往往会碰到很多问题，下面我们以一条实例来探讨组织树资源的表结构设计和功能点。
表结构设计（以mysql为基础）
我们要设计一个树状结构的数据存储，第一反应是在表里面加一个parent_id
这肯定没有错，我们通过数据的id和parent_id就能组装成整个的树结构，但是比如我们的需求往往不是这么简单，比如我需要关注节点的状态，根据状态去做图标的显示和功能的限制，那么我们就需要添加一个status字段
同时我们的树不可能无限制构建，递归是一个非常消耗资源的事情，所以我们需要限制树的高度，这里我们可以通过加入一个level字段去控制树的层级
也可能我们有这样的需求，我们关心节点之间的顺序，于是我们又要添加一个order_num来控制排序
综合上述，我们得出一张这样的表结构
字段名称 | 字段类型 | 字段描述 | 是否唯一 | 是否非空 |
id | int(11) | 主键 | 是 | 是 |
parent_id | int(11) | 父id | 否 | 是 |
level | tinyint(2) | 层级 | 否 | 是 |
parent_path | varchar(640) | 当前节点在树节点中的路径，以/分割，如0/1/2/ | 否 | 是 |
name | varchar(255) | 名称 | 否 | 否 |
status | tinyint | 是否启用 | 否 | 是 |
order_num | int(5) | 顺序 | 否 | 是 |
字段的用途大家都应该明白，但是这里有个parent_path有点迷糊，在树结构的环境下往往有这么个需求，查找某个节点的所有子节点，如此，按照一般思路我们需要递归去查询，对数据库造成的性能损失
这里我们引入了parent_path字段，每次需要查询子节点的时候，只需要执行sql:
SELECT id from tree_test where path like '0/1/2/%'当然还有一种思路是path按照逗号分割（0,1,2），这样我们可以直接使用mysql的内置函数FIND_IN_SET
SELECT id from tree_test where FIND_IN_SET('1',path);但是，通过我们查看执行计划，like的方式可以走索引，而FIND_IN_SET不会走，所以我们选择like的方式。
你以为到这里就结束啦，当然没有，节点的顺序除了同节点间的交换插入，可能从其他层级进入当前层级，或者从当前层级扩散到其他层级，万物都是一把双刃剑，parent_path给我们带来方便的同时，我们每次在节点移动的时候需要变更这个path,增加了一定的工作量。
那么我们在挪动节点的时候，顺序是怎么维护的呢？
功能设计
我整理了一个图，其中x表示元素的起始顺序，y表示元素的目标顺序，当我们在节点进行变更时需要按照一下规则维护order_num字段
