2

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

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

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

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

这使我想到以下问题

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

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

目前我正在探索 InfiniteGraph 和 TitanDB。

4

1 回答 1

0

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

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

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

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

于 2014-03-31T00:15:37.463 回答