对于树形菜单，想必大家都不陌生，这种业务数据，由于量小，关系复杂，所以在关系型数据库中，存储的格式一般都如下所是：

id,name,pid
01,bigdata,00
002,hadoop,01
003,spark,01
02,search,01
03,lucene,02
04,es,02

有没有人感到困惑，为啥不使用，主外键表，存储这种数据，而非得只使用一张表来存储呢？结果导致查询非常受限，通常只能递归出所有节点，然后对比找到指定数据。

如果使用主外键表存储，通常关系越复杂需要的外键表越多，假如你有8层关系，意味着你需要join到8个外键表，才能获取一条完整数据，这样一 比，大多数时候，还是将这种数据，存储在一个表中，然后通过父字段进行找到上一级，当然这种场景下，通常数据量都不会太大，因为递归时间和数据量成正比。

那么当数据量超级大时，应该怎么设计才能支持各种各样的查询，也能提供良好的性能呢？

这个时候用关系型数据库存储肯定不行，超过几十万的数据，递归都需要十几或者几十秒的遍历时间，这样的性能是远远不达标的。

而图形数据库的出现，则是解决这个问题的神器，图形数据库就是为了存储超级复杂的依赖关系和提供高效的查询性能而应劫而生的，比如社交网络，知识图谱，地图最优路径等等。

当然树形菜单的数据，也可以存储在neo4j里面，从而提供强大的查询分析功能，neo4j的小数据下的例子与xmind的思维导图非常类似，都有着一图胜万语强大表现能力。



比如存储从小学到高中的课程里面的章节关系和知识点，如果我们用关系型数据库存储，
提供的分析查询能力非常有限，只能查某个确定节点的父节点，如果想找具体的任意一个节点需要递归遍历所有数据，或者想查某一个科目下，包含知识点路径最长的是哪个，等等就比较复杂了。

图形数据库里面描述数据，是通过节点和关系来描述的，关系必须有开始节点和结束节点
，节点和关系都可以有属性。



下面说下将树形菜单，存储到neo4j的思路：

（1）递归的每行数据是一个节点，首先插入所有的节点

（2）找到每个节点的父节点做为start节点，本身作为end节点，建立起关系


上面的两个步骤既可以分开执行，也可以单独执行，具体可以参考使用neo4j的api。

导入完的几个效果图如下，（注意这里限制深度了，不限制这个图密度可能非常大）