本文介绍了用于 Cypher 中类似操作的 Neo4j 关系命名约定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道对命名关系没有约束,尽管很难得到一个指导方针并在我们可能遇到的所有关系上使用它.

I am aware of the absence of a constraint for naming relationships, though it is tough to get one guideline and work with it over all the relationships that we might encounter.

你会选择这样的吗:

(u:User)-[:LIKES]->(p:Post)
(u:User)-[:LIKES]->(c:Comment)

然后根据标签进行查询;或者像这样:

and then query based on the label; Or something like this:

(u:User)-[:LIKES_POST]->(p:Post)
(u:User)-[:LIKES_COMMENT]->(c:Comment)

另一种情况是线程聊天应用程序,其中 User 可以与多个其他用户启动一个线程,这是我想到的结构:

Another case is a threaded chat application where a User can start a thread with multiple other users, here's the structure I have in mind:

# the thread
CREATE (ct:ChatThread {created_at: timestamp()})

# the thread starter
(u:User {user: 1})<-[:IN_THREAD {type: 'owner'}]-(ct)

# members of the thread
(u:User {user: 2})<-[:IN_THREAD {type: 'member'}]-(ct)
(u:User {user: 3})<-[:IN_THREAD {type: 'member'}]-(ct)

推荐答案

我将解决您发布的第一个示例:

I'll address the first example you posted:

(u:User)-[:LIKES]->(p:Post)
(u:User)-[:LIKES]->(c:Comment)

对比

(u:User)-[:LIKES_POST]->(p:Post)
(u:User)-[:LIKES_COMMENT]->(c:Comment)

这本质上是细粒度与粗粒度的关系,如图数据库一书(第 1 章)中所述.4 - 构建图形数据库应用).考虑一下您的使用情况:

This is essentially fine-grain vs. coarse-grain relationship ,as described in the Graph Databases book (ch. 4 - Building a Graph Database Application). Think about your usage:

  • 如果您总是想查询用户喜欢什么,无论是Post 还是Comment,那么LIKES 都非常有用.
  • 如果您想专门搜索用户的Posts 或用户的喜欢,则可以使用诸如LIKES_POST 之类的细粒度关系类型伟大的.如果您继续使用更通用的 LIKES,则需要注意过滤中的实体类型.而且...如果此列表随着时间的推移而增长,您将需要修改您的查询以包含新类型(如果此类型列表是无界的,它可能会变得有点麻烦).
  • 如果您经常混淆,您可能需要考虑在这些节点之间建立细粒度和粗粒度的关系.
  • If you always want to query what a user likes, regardless whether it's Post or Comment, then LIKES works great.
  • If you want to search specifically for a user's Posts, or a user's Likes, then fine-grain relationship types such as LIKES_POST work great. If you stayed with the more generic LIKES, you'd need to pay attention to the entity types in your filtering. And... if this list grows over time, you'll need to modify your queries to include the new types (and if this type list is unbounded, it could get a bit cumbersome).
  • If you often mix it up, you may want to consider having both fine- and coarse-grain relationships between these nodes.

这篇关于用于 Cypher 中类似操作的 Neo4j 关系命名约定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

11-03 11:37