使用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)，在後臺留言諮詢。 技術債不能欠，健康債更不能欠， 求道之路，與君同行。