Question

简短而简单的问题：

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

有哪些优点/缺点？我对你的意见感兴趣。

Answer 1

使用flag选项的一个优点是当delete vertex删除任一用户节点时，OrientDB将自动删除友元请求边缘以保持图形一致性。如果您为请求使用单独的节点，则需要手动删除该节点。

性能方面，我猜，您链接的问题也与OrientDB相关。

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

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

使用User1（V）这样的模型---友谊（E）----＆gt; User2（V）足以表示用户之间的友谊绑定，并且通过使用属性，您可以实现请求中的所有工作流程完成。这个设计是非常基本的，所以当涉及到查询/遍历时你会有一个标准的复杂性....更多的是你在属性上添加约束会更加困难......一个缺点就是Edge不是一个顶点这将影响它与其他顶点的交互，如果你需要这样的交互，那么友谊是一个顶点的方法就是你的方法。

Answer 3

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

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

找朋友更容易：

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

查找请求更容易：

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

他们很可能比某些财产的指数更快。

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

3 个答案: