图数据库，为好友请求创建节点？

Question

简短的问题：

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

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

Answer 1

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

Answer 2

使用 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 语法和术语，那么此选项可以让您编写非常易于理解的代码。

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

Answer 3

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

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

找朋友更容易：

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

查找请求更容易：

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

而且它们很可能比某些属性上的索引更快。

图数据库，为好友请求创建节点？

Graph DB, create node for friend request?

friend

request

graph-databases

orientdb