我知道命名关系缺乏约束，尽管很难获得一个指导方针并在我们可能遇到的所有关系上使用它。
你会选择这样的东西吗：
(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)
我将解决您发布的第一个示例：
(u:User)-[:LIKES]->(p:Post)
(u:User)-[:LIKES]->(c:Comment)
vs
(u:User)-[:LIKES_POST]->(p:Post)
(u:User)-[:LIKES_COMMENT]->(c:Comment)
这本质上是细粒度与粗粒度的关系，如图数据库 http://graphdatabases.com/书（第 4 章 -构建图数据库应用程序）。想想你的用途：
- 如果你总是想查询用户喜欢什么，无论它是
Post or Comment, then LIKES效果很好。
- 如果您想专门搜索某个用户的
Posts，或用户的Likes，然后是细粒度关系类型，例如LIKES_POST工作得很好。如果你继续使用更通用的LIKES，您需要注意过滤中的实体类型。并且...如果此列表随着时间的推移而增长，您将需要修改查询以包含新类型（如果此类型列表是无界的，则可能会变得有点麻烦）。
- 如果您经常混淆它们，您可能需要考虑在这些节点之间同时拥有细粒度和粗粒度的关系。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
