Question

我知道没有对命名关系的约束，但很难得到一个指南并在我们可能遇到的所有关系上使用它。

你会选择这样的东西：

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

然后根据标签查询;或类似的东西：

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

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

# 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)

Answer 1

我将解决你发布的第一个例子：

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

VS

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

这基本上是细粒度与粗粒度的关系，如Graph Databases书中所述（第4章 - 构建图数据库应用程序）。想想你的用法：

如果您总是想查询用户喜欢的内容，无论是Post还是Comment，那么LIKES效果都很好。
如果您想专门搜索用户的Posts或用户的Likes，那么LIKES_POST等细粒度关系类型效果很好。如果您使用更通用的LIKES，则需要注意过滤中的实体类型。并且......如果此列表随着时间的推移而增长，您将需要修改您的查询以包含新类型（如果此类型列表无限制，则可能会有点麻烦）。
如果您经常混淆它，您可能需要考虑在这些节点之间同时存在细粒度和粗粒度关系。

关于Cypher中类似操作的Neo4j关系命名约定

1 个答案: