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来保存您的零件和产品,但如果它是一个不错的选择,那么您必须回答以下问题: