图模式设计：用户->发布->评论答案

【问题标题】：graph schema design: users->post->comments图模式设计：用户->发布->评论
【发布时间】：2020-01-16 16:23:33
【问题描述】：

我刚开始使用 neo4j，我对如何建模 users->post->cmets 模式有些疑问......实际上我做了这样的事情：

type User {
  uuid: ID!
  username: String
  posts: [Post] @relation(name: "HAS_POSTS", direction: "OUT")
  comments: [Comment] @relation(name: "POST_COMMENTS", direction: "OUT")
}

type Post {
  uuid: ID!
  text: String
  owner: User @relation(name: "HAS_POSTS", direction: "IN")
  comments: [Comment] @relation(name: "HAS_COMMENTS", direction: "OUT")
}

type Comment {
  uuid: ID!
  text: String
  owner: User @relation(name: "POST_COMMENTS", direction: "IN")
}

保存引用对象的 uuid，例如，每个帖子都将所有者 uuid 作为属性，并且它也具有关系（对于 cmets 也是如此），但我不是 100% 认为这是正确的。阅读这篇文章： https://neo4j.com/developer/modeling-designs/

我理解为什么使用关系比属性更好，但是如果我想编辑帖子并确保只有帖子的所有者有权这样做，我想通过 uuid 搜索帖子用户的帖子和 uuid，然后在该特定节点上设置数据......像这样：

MATCH (p:Post) WHERE p.uuid = post.uuid AND p.owner = $cypherParams.user.uuid
      SET p += post
      RETURN p

这种模式好吗？还是保存所有者属性没有用，并且会破坏我的数据的一致性？

非常感谢

【问题讨论】：

标签： database-design graph neo4j schema

【解决方案1】：

对于任何数据库中的数据建模（包括图表），我认为没有很多明确的答案。我们可以做的是查看如果您要使用关系，特定的“编辑帖子”查询可能会如何，以便您查看比较。

首先，让我们伪造您的 cypherParams 变量以进行测试：

:param cypherParams => {
  user: {
    uuid: 123
  },
  post: {
    text: 'Made the post better',
    uuid: 2
  }
}

现在让我们用 Post 和 User 节点来模拟一个简化版本的问题：

MERGE (u1: User { uuid: 123, name: 'Pablissimo' })
MERGE (u2: User { uuid: 234, name: 'Francesco' })
MERGE (p1: Post { uuid: 1, text: 'This post is great' })
MERGE (p2: Post { uuid: 2, text: 'This post not so great' })
MERGE (p3: Post { uuid: 3, text: 'This post is pretty good' })
MERGE (u1)-[:HAS_POST]->(p1)
MERGE (u1)-[:HAS_POST]->(p2)
MERGE (u2)-[:HAS_POST]->(p3)
RETURN p1, p2, p3, u1, u2

鉴于此，如果我是尝试更新帖子 2 的用户 123，该查询的外观如何？

MATCH (u: User { uuid: $cypherParams.user.uuid })-[:HAS_POST]->(p: Post { uuid: $cypherParams.post.uuid })
SET p += $cypherParams.post
RETURN p

它实际上并不比 Post 节点具有 owner 属性的查询复杂，但它具有依赖于图形数据库优势的清晰数据模型的所有优点。

存储冗余数据感觉像是一种过早的优化——在您发现需要它来摆脱困境之前，我建议您的原始模型看起来很适合图表。如果这还不足以让您充满信心，那么请进行试验，尝试这两种方法并查看查询的外观以及模型感觉如何用于您的用例。请记住 - 您始终可以将图表重构为关系或存储额外属性，然后随着需求的变化再次返回。

【讨论】：