图形数据库建模

Question

来自 SQL/NoSQL 背景，我发现在 Graph DB 上建模（高效地）最简单的练习非常具有挑战性。

虽然不同的技术有局限性和最佳实践，但我不确定我在创建模型时使用的思维方式是否正确，因此，我需要指导、建议和/或资源来帮助我获得更接近正确的做法。

---

我尝试的初始练习是在图形数据库中表示文件共享整个目录（子文件夹和文件）。例如，我想包含的一些属性和查询是；

• 文件夹的层次结构
• 当前节点的聚合大小
• 能够根据创建文件/文件夹的人进行搜索
• 能够搜索文件类型

这让我想到了以下问题

1. 何时/哪些属性应该用于边缘。只有我打算搜索的那些？只有关系？

2. 我是否应该扩展我的图形功能，例如，搜索大于 X 的文件？如何尝试最大化模型的未来功能/灵活性，以使此类更改不会造成巨大影响。

---

目前我正在探索 InfiniteGraph 和 TitanDB。

Answer 1

1) 我能想到的描述文件夹层次结构中边缘的唯一属性是它是包含关系还是包含关系。

（如果您决定将所有边都考虑在内，您甚至不需要它。在您的情况下，看起来您几乎总是会询问后代以搜索并返回聚合大小）。

这比网络或边缘可能具有不同类型的层次结构要简单得多。想想一个组织结构图，它不仅跟踪谁管理谁，而且跟踪谁支持谁、指导谁、骚扰谁等等。

2）我对你提到的两个数据库不熟悉，但是 Neo4J 允许在节点属性上建立索引，所以在 file_size 上添加索引应该不会有太大影响。它也是“无模式”的，因此您可以动态添加属性，并且各个节点可能包含不同的属性。