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

问题描述

我刚开始使用Neo4j和Graph数据库，并且想知道嵌套层次树是否是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.

推荐答案

好吧，因为树实际上是使用图形数据库存储树的图形似乎完全适合我.效果最佳的取决于您的数据访问模式，但是基本上树只是图形的一种专业化.

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链接(从根"Article"开始).然后，它仅查看该路径中的节点，并返回最后一个项目(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.

编辑-值得一说的是，可变长度路径匹配"，在上面的查询中就是这样:<-[:reply*1..]-对我来说是图表的前三大卖点之一数据库.正是这些图数据库非常容易实现，而关系关系之类的其他大多数替代方法却变成了痛苦的练习.因此，如果您需要做这种事情(例如，在这里组装一棵完整的树)，那么我认为这是图形数据库的理由，因为您正在其基本强度领域中使用它.

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屋！