2

我最近开始研究 RavenDB，并尝试看看它是否适合我们的某些项目。但是，我遇到了一些关于建模简单数据结构的“正确”方法的问题。我将尝试描述它：

  • 有 3 种类型的对象：指南、类别和链接
  • 一个“根”指南可以包含 0 个或多个子指南
  • 一个指南可以包含 0 个或多个类别
  • 一个类别可以包含 0 个或多个链接

从视觉上看，结构将是：

  • 根指南（0个或更多）
    • 子指南（0个或更多）
      • 类别（0个或更多）
        • 链接（0个或更多）
    • 类别（0个或更多）
      • 链接（0个或更多）

在实际数据中，大约有20个根Guide，每个根Guide下大约有3-5个子Guide。在每个指南（根指南和子指南）下都有 15-25 个类别。每个类别下有 5 到 20 个链接。

我最初的想法是像这样建模（简化模型）：

Guide
---------------
Id
ParentGuideId
Title

Category
---------------
Id
GuideId
Title

Link
---------------
Id
CategoryId
Title

这几乎是关系模型，我意识到这可能不是在 RavenDB 中建模数据的正确方法。那么替代方案是什么？我想问题是我不想像这样存储层次结构：

Guide
---------------
Id
Title
SubGuides
Categories

SubGuide
---------------
Title
Categories

Category
---------------
Title
Links

Link
---------------
Title

因为它会导致文档可能包含数千个子对象。请记住，上面的模型是简化的。实际上，每种类型都有更多的数据，因此如果我们采用这种模型，RavenDB 中的 20 个根指南文档将会非常庞大​​。

有没有其他选择？也许这是我多年来对关系数据库的不良教育，但也许这种情况根本不适合 RavenDB，也适合 SQL？

编辑（添加基本查询）

访问数据相当简单。我有以下要求：

  1. 选择包含所有子指南的根指南列表。
  2. 对于特定指南（根或子），获取所有子指南（如果是根）、类别和链接。

这基本上就是我所需要的。但是，评估 RavenDB 或类似数据库的原因之一是添加了一些搜索功能。正如我已经提到的，还有一些关于链接、类别和指南的更多信息，例如描述、标签等，因此能够搜索所有这些信息会很好。

4

1 回答 1

2

我会处理事情，使指南成为一个文件。类别和链接嵌入在该文档中。

一个指南可以有一个子指南的集合。

第一个查询是查询所有指南及其子项。你这样做：

session.Query<Guide>().Include(x=>x.SubGuides).Where(x=>x.Parent == null).ToList();

这将在一个服务器查询中为您提供所有内容。

session.Include<Guide>(x=>x.SubGuides).Load("guides/123")

这将为您提供所有子指南的指南。

于 2012-09-11T12:10:54.997 回答