Mongodb属性的架构设计

Question

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

在旧版数据库中，我具有下表

财产（持有财产数据信息）

• PropertyID
• 地址
• 邮政编码
• 州
• 国家
• 状态
• 类型

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

示例：厨房，厨房> Windows

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

• 模板ID
• TemplateName示例：仅检查内部结构

InspectionTemplateField（检查员必须填写字段）

• InspectionTemplateFieldID
• 模板ID
• PropertyFieldID
• 是强制性的

检验（检验信息）

• 检验编号
• 开始日期
• 截止日期
• LastInspectionDate
• 分配给
• 模板ID
• 状态

条件（属性字段的条件）

• ConditionID
• 条件名称

示例：良好，公平，需要替换，差，需要修复

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

• PropertyID
• 检验编号
• ConditionID
• PropertyFieldID
• PropertyFieldOldValue（需要从上次检查中复制值）
• PropertyFieldNewValue
• 图片
• 评论

我对mongodb模式重新设计的问题是

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

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

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

问候，托马斯。

Answer 1

问题1：

我能想到的几点是：

参考模型，如果：

• 嵌入文档将导致文档超过阈值大小（我想每个文档16兆字节）。
• 您不介意为一组操作多次提取文档。

嵌入式模型，如果：

• 对同一文档和相关文档进行的大量操作
• 文件尺寸不大

问题2：我不明白这个问题。 抱歉! 尝试重新构图。