database - RavenDB 是否适合这个概念？

Question

首先，一个警告:我对文档数据库背后的概念相当陌生，所以这可能是一个完全显而易见的问题。

我需要设计一个系统来维护构成高度复杂产品的零件的深层层次结构目录。它将详细说明构成每个部分的物理组件 - 每个部分都可以是其他部分的组件 - 一直到最终产品。像这样:

Widget
 |- Sprocket
 |  |- A4 nut
 |  |- B15 screw
 |  |- Sprocket Backshell
 |- Flange
 |  |- A4 washer
 |  |- Flange Housing
 |- Widget Assembly

此示例中的小部件稍后可以作为其他产品下的部件合并。

每个产品可能包含数万到数十万个零件，并且每种类型的组件都具有必须维护的不同的、不相关的属性。这些属性可以包括相关部分之间的连接。

我们现在在 SQL Server 中有这个系统的一个设计不佳的版本，它是一个包含大约 120 列和数百万条记录的单一平面表。此表中大约 85% 的字段为空。我的工作是用更易于维护、更高效且更不容易出错的东西取而代之。

在关系数据库中有效地构建它意味着规范化——在这种情况下，每种类型的零件都有一个表。我怀疑这会是个问题，因为有数百种零件类型，并且会定期添加具有自己特定属性的新零件类型。

我想为此使用 RavenDB，因为文档数据库适合部件的动态特性，但我不知道它是否适合，或者我将如何在文件条款。产品本身是根对象，但由于它们的大小，我无法将产品存储为单个文档。

RavenDB 是否适合这个概念？是否有关于如何在文档中最好地表示它的任何指示？

Answer 1

Erik，文档数据库是否适合这种情况以及哪种结构最好取决于您要对这些数据执行哪种操作。

您当然可以使用 RavenDB 来持久化您的零件和产品，但要回答它是否是一个好的选择这个问题，您必须回答以下问题:

• 您需要什么样的查询？
• 读取或写入对您的系统性能更重要的是什么？
• 您能接受最终一致性吗？
• 你能利用 map/reduce 索引等功能吗？
• 等等