图形数据库建模

Question

来自SQL/NoSQL背景我发现对图形数据库中最简单的练习进行建模（有效率）是相当具有挑战性的。尽管不同的技术有其局限性和最佳实践，但我不确定我在创建模型时使用的思维方式是否正确，因此，我需要指导，建议和/或资源来帮助我更接近正确的做法。

---

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

• 文件夹的层次结构
• 在当前节点
• 如果能够根据谁创建的文件/文件夹
• 如果能够在文件类型搜索来搜索的总大小

这使我对以下问题

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

2. 我是否应该扩展我的图形功能，例如，搜索大于X的文件？如何最大限度地发挥模型的未来能力/灵活性，从而使这些变化不会造成巨大影响。

---

目前我正在探索InfiniteGraph和TitanDB。

Answer 1

1）我能想到的描述文件夹层次结构边缘的唯一属性是它是包含还是包含关系。如果你决定考虑你所有的边缘，你甚至不需要这样做，就你而言，看起来你几乎总是在询问后代搜索并返回聚合大小。

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

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