如何在 Neo4j 中实现嵌套树? [英] How to realize a nested tree in Neo4j?

问题描述

我刚刚开始使用 Neo4j 和图形数据库，想知道嵌套层次树是否是 Neo4j 的一个很好的用例.一个常见的例子是一组嵌套的注释.例如:

I am just getting started with Neo4j and Graph Databases and was wondering if nested hierarchical trees are a good use case for Neo4j. A common example would be a nested set of comments. For example:

 - Article
  - Comment 1 on Article
     - Comment 2 on Comment 1
     - Comment 3 on Comment 1
         - Comment 4 on Comment 3
  - Comment 5 on Article

据我所知，文章和评论都是节点.而且每条评论都会有亲子关系.获得对文章(1 和 5)的所有直接评论很容易.但是检索整个集合怎么样?

As I understand it, the article and the comments would each be nodes. And each comment would have a parent-child relationship. Getting all direct comments on the article (1 and 5) would be easy. But how about retrieving the whole set?

请原谅使用外行术语.我认为这样比在混淆每个人的同时尝试使用适当的词更好.

Please excuse the use of layman terms. I figured it is better this way then trying to use the appropriate words while confusing everyone.

推荐答案

嗯，因为 trees实际上是使用图形数据库存储树的图形对我来说似乎完全合适.哪种表现最好取决于您的数据访问模式，但基本上树只是图的一种特化.

Well, because trees actually are graphs using a graph database to store a tree seems entirely appropriate to me. What will perform the best will depend on your data access patterns, but basically trees are just a specialization of graphs.

是的，在您的情况下，树中的元素"将是节点，而嵌套"将是关系.因此，您可以通过以下方式模拟示例:

Yes, in your case the "elements in the tree" would be nodes, and the "nesting" would be relationships. So here's how you might mock up your example:

CREATE (root:Article {label: "Article"}),
       (c1:Comment {label: "Comment 1"}),
       (c1a:Comment {label: "Comment 2 on comment 1"}),
       (c1b:Comment {label: "Comment 3 on comment 1"}),
       (c1b1:Comment {label: "Comment 4 on comment 3"}),
       (c2:Comment {label: "Comment 5 on article"}),
       (root)<-[:reply]-(c1),
       (c1)<-[:reply]-(c1a),
       (c1)<-[:reply]-(c1b),
       (c1b)<-[:reply]-(c1b1),
       (root)<-[:reply]-(c2);

这只是创建了一堆节点和关系，模仿您提供的结构.在这里，我选择始终使用 :reply 来连接事物.

This just creates a bunch of nodes and relationships, mimicking the structure you provided. Here I've chosen to always use :reply to connect things.

现在，得到一切"只是意味着遍历我们创建的所有 :reply 关系:

Now, "getting everything" just means traversing all of the :reply relationships we created:

MATCH p=(a:Article {label: "Article"})<-[:reply*1..]-(otherThing) 
WITH nodes(p) as nodes
RETURN nodes[length(nodes)-2] as InResponseTo, 
       nodes[length(nodes)-1] as CommentOrReply;

这个查询的作用是遍历任意数量的 :reply 链接(从根文章"开始).然后它只查看该路径中的节点，并返回最后一项 (CommentOrReply) 以及它响应的内容(倒数第二项).

What this query does is traverse any number of :reply links (starting from the root "Article"). Then it only looks at the nodes in that path, and returns the last item (CommentOrReply) and what it was in response to (the second last item).

结果如下:

+-------------------------------------------------------------------------------------+
| InResponseTo                             | CommentOrReply                           |
+-------------------------------------------------------------------------------------+
| Node[18]{label:"Article"}                | Node[19]{label:"Comment 1"}              |
| Node[19]{label:"Comment 1"}              | Node[20]{label:"Comment 2 on comment 1"} |
| Node[19]{label:"Comment 1"}              | Node[21]{label:"Comment 3 on comment 1"} |
| Node[21]{label:"Comment 3 on comment 1"} | Node[22]{label:"Comment 4 on comment 3"} |
| Node[18]{label:"Article"}                | Node[23]{label:"Comment 5 on article"}   |
+-------------------------------------------------------------------------------------+

这就是你遍历整棵树的方式.

So that's how you traverse an entire tree.

EDIT - 对于它的价值，可变长度路径匹配"，在上面的查询中只是这一点:<-[:reply*1..]- 对我来说是图形数据库的三大卖点之一.正是图 DB 使之变得非常简单，大多数其他替代方案(如关系)都变成了曲折痛苦的练习.所以如果你需要做那种事情(比如这里，组装一整棵树)，我会声称这是一个图形数据库，因为你在它的基本优势领域使用它.

EDIT - for what it's worth, "variable length path matching", which in the query above was just this bit: <-[:reply*1..]- is for me one of the top 3 selling points for a graph database. It's precisely that which graph DBs make really easy, that most of your other alternatives like relational make into a tortuously painful exercise. So if you need to do that sort of thing (like here, assembling an entire tree) I would claim that argues for a graph DB because you're using it in its area of fundamental strength.

这篇关于如何在 Neo4j 中实现嵌套树?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！