Mongodb架构设计的属性

Question

我打算从传统的关系数据库中重新设计我的遗产检查以使用mongodb。我对mongodb架构设计很陌生，并希望您就如何设计架构提出建议

在旧数据库中，我有以下表格

属性（保存属性数据信息）

• 物业ID
• 地址
• 邮编
• 国家
• 国家
• 状态
• 类型

PropertyField（层次结构中属性的动态字段）   - FieldID   - FieldParentID   - FieldName   - FieldDescription

示例：厨房，厨房＆gt;视窗

InspectionTemplate（需要检查属性字段的模板）

• TemplateID
• TEMPLATENAME 示例：仅检查内部结构

InspectionTemplateField（检查员填写时需要填写字段）

• InspectionTemplateFieldID
• TemplateID
• PropertyFieldID
• IsMandatory

检查（检验信息）

• InspectionID
• 开始日期
• DUEDATE
• LastInspectionDate
• AssignedTo
• TemplateID
• 状态

条件（财产领域的条件）

• ConditionID
• ConditionName

示例：良好，公平，需要更换，差，需要维修

PropertyCondition（属性的当前和先前条件）

• 物业ID
• InspectionID
• ConditionID
• PropertyFieldID
• PropertyFieldOldValue（需要复制上次检查的值）
• PropertyFieldNewValue
• 图片
• 评论

我对mongodb架构重新设计的问题是

1. 我应该使用嵌入式或参考数据模型吗？我的理解是，嵌入式数据模型最适合这种情况，因为我需要加载单个属性并经常更新整个属性关联数据，例如检查员登录移动应用程序并选择要检查的属性。系统将加载所有属性信息，包括所有属性动态字段。但是，如果我使用此数据模型，它可能会影响性能，因为我需要将大量数据加载到移动设备并将信息更新回服务器。对此更好的想法吗？
2. 我需要使用哪种类型的树数据模型来遍历和更新所有属性字段信息？例如，我需要更新字段的条件

 Exterior 
|   |_ FrontDoor
|   |_ BackDoor
|   |_ Fence
|Gargage
|   |_ Walls
|   |_ Windows
|MasterBedRooms
|   |_ Sink
|   |_ Cabinet    
|Fireplace

根据Mongodb树数据模型模式，物化路径最适合这种情况，因为它为查询节点和子节点提供了最佳性能。但是，该文档没有提到更新或插入新节点到树的性能是否良好。

此致 托马斯。

Answer 1

问题1：

我能想到的一些观点是：

参考模型，如果：

• 嵌入文档会导致文档超过阈值大小（我猜每个文档的大小为16 MB）。
• 您不介意多次为一组操作提取文档。

嵌入式模型，如果：

• 要对同一文档和相关文档执行大量操作
• 文档大小不大

问题2： 我无法理解这个问题。抱歉!尝试重新构建。