使用 ArangoDB，具有 x 个边定义的 1 个命名图与具有 1 个边定义的 x 个命名图之间的实际区别是啥？

Posted 2023-04-12

【中文标题】使用 ArangoDB，具有 x 个边定义的 1 个命名图与具有 1 个边定义的 x 个命名图之间的实际区别是啥？

【英文标题】：With ArangoDB what is the practical difference between 1 named graph with x edge definitions vs x named graphs with 1 edge definition?使用 ArangoDB，具有 x 个边定义的 1 个命名图与具有 1 个边定义的 x 个命名图之间的实际区别是什么？

【发布时间】：2021-12-11 13:36:28

【问题描述】：

差异仅与逻辑/内务有关吗？

我确实阅读了this question，但那里的答案仅涉及 1 个边定义与多个边定义在现在已经包含在 documentation 中的图表。所以我很好奇。

【参考方案1】：

我使用 Arango 6 年了，不使用 Graph 对象，我所有的查询都只是 AQL 查询，这意味着您不需要使用 Graph 来利用图数据库的好处并执行遍历。

我认为 Arango 中的“图表”的方式是，它是您的集合的有限/精选视图，可查询，但如果您希望它在删除时管理某种程度的完整性，这也很有帮助。

总的来说，它会减慢遍历速度，所以我发现最好避免它们。我决定的一个关键驱动因素是我不需要视图，如果我删除连接的顶点，我也不需要系统来处理边的删除，但这只是我的用例。

【讨论】：

谢谢，我需要删除/边缘完整性图提供，所以在这种情况下处理图是必须的。我不想在客户端代码中处理它。

我在 Foxx 中处理这个问题，它是一个微服务层，可以作为外部 REST 客户端的数据库接口。我肯定会推荐 Foxx，因为它允许您添加业务逻辑、安全性以及对外部客户端隐藏数据模型的某些部分。这为您提供了更多与确保数据库受到保护和正确使用相关的选项，而不仅仅是一个图表。我从不允许将 AQL 查询发送到数据库，所有数据交互都通过 Foxx 作为标准 REST API 调用传递。如果可以的话，看看 Foxx，这是值得的。

我绝对考虑过 foxx 并在这里和那里使用它，但即便如此，我还是会使用图形交互方法来实现边缘一致性。如果我手动选择文档并按照它们的边缘进行删除操作，这将成为维护负担（某些模式更新需要重新访问删除端点以保持一致性）。老实说，如果我想自己管理这一切，我不会一开始就使用 ArangoDB，不是吗？如果您想自己构建和管理图表，任何文档存储（甚至是关系 SQL）都可以使用。

SQL 性能随着图遍历的深入而呈指数级下降，这是 Arango 的关键优势。