使用neo4j存储树形无限级菜单

对于树形菜单，想必你们都不陌生，这种业务数据，因为量小，关系复杂，因此在关系型数据库中，存储的格式通常都以下所是：

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。

导入完的几个效果图以下：（注意这里限制深度了，不限制这个图密度可能很是大）

有什么问题能够扫码关注微信公众号：我是攻城师(woshigcs)，在后台留言咨询。 技术债不能欠，健康债更不能欠， 求道之路，与君同行。