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

您需要什么样的查询？

对您的系统，读取或写入更重要的是什么？

你能忍受最终的一致性吗？

您能否采用地图/缩小索引等功能？

等

Answer 2

这似乎非常适合关系数据库：

Part
  - PartId
  - Name
  - ...more fields..

PartRelations
  - ParentPartId (PK)
  - ChildPartId (PK)

使用该模式，您可以轻松构建大量的零件层次结构，一次存储零件信息，然后只存储父零件与子零件的关系。

您可以进一步向此添加属性模型，以允许您的零件具有所有不同的属性

PartAttribute
   - PartId
   - Attribute
   - Value

属性，如果你想进入另一个表属性

，可以进一步细分

Attribute
   - AttributeId
   - AttributeName
   - ..datatype?.. (for pretty formatting logic or other..)

然后在PartAttribute表中，您可以使用AttributeId而不是Attribute。在实践中，我发现只使用一个字符串而不是一个列出它们的属性表，编码更容易，并且易于维护

您可以使用文档数据库，但由于这些内容非常相关，我不确定它是否合适，我相信有些人可能不同意我的看法。

RavenDB是否适合这个概念？

2 个答案: