图DB，为好友请求创建节点？

Question

简短的问题：

对于社交网络平台，您是为朋友请求创建单独的节点，确认后创建边缘，还是直接创建边缘并设置确认标志？

什么是优点/缺点？我对你的评论很感兴趣。

Answer 1

我相信你也应该考虑到你可以使用的内存。如果您将该信息存储在边缘，这可能意味着您必须在该属性上定义一个索引才能获得更快的查询。这意味着需要更多的内存。

我建议您将朋友请求存储在不同的节点中。

找朋友比较容易：

select expand(both('Friend')) from #12:0

查找请求更容易：

select expand(in('Request')) from #12:0

而且，它们很可能比某些房产的指数更快。

Answer 2

使用标志选项的一个优点是，当用户节点中的任何一个被delete vertex删除时，好友请求边缘将由OrientDB自动删除，以保持图的一致性。如果对请求使用单独的节点，则需要手动删除该节点。

就性能而言，我想，您所链接的问题也与OrientDB相关。

对于这样的决定，我还会考虑代码的可读性。使用图形DB的一个优点是代码变得更容易理解和推理。因此，您可以编写针对不同选项的查询，并判断哪些代码更具可读性。让我们尝试一下标志选项：

# create
CREATE EDGE Friend 
    FROM (SELECT FROM User where name = "Alice") 
    TO (SELECT FROM User where name = "Bob") 
    SET status = "requested"  # or confirmed = False
# confirmed
UPDATE Friend SET status = "confirmed"  # or confirmed = True
    WHERE out.name = "Alice" AND in.name = "Bob"
# query
SELECT in.name FROM Friend 
  WHERE out.name = "Alice" AND status = "confirmed"  
# output: Bob
# another method
SELECT outE(Friend)[status = "confirmed"].in.name
  FROM User WHERE name = "Alice"
# output: Bob

我认为，如果您熟悉图形作为数学对象，并且熟悉OrientDB语法和术语，则此选项使您能够编写非常容易理解的代码。

如果您不喜欢这个选项，作为将请求保存在不同节点(类/表)中的替代方法，我还建议将它们作为LINKSET或类似的东西存储在用户节点中。

Answer 3

使用User1(V)-- friendship (E)->User2 2(V)这样的模型就足以表示用户之间的友好绑定，通过使用属性，您可以实现从请求到完成的所有工作流。这个设计非常基本，所以当涉及到查询/遍历时，您将有一个标准的复杂性。如果您对属性添加约束，这可能会更加困难……一个缺点是，边缘不是顶点，这会影响到它与其他顶点的交互，如果你需要这样的交互，那么友谊就是顶点的方法是可行的。