我有一个 aggerate 数据模型（认为一个带有属于它们的小部件的客户实体作为嵌入实体的列表）。
当我搜索客户（例如 DocumentDBRepository.GetItemsAsync）时，这将为客户数据模型以及每个小部件提供水合。出于效率原因，我真的不需要客户搜索来考虑小部件。
在文档数据库（例如“LiteCustomer”实体）中是否有任何策略？我怀疑这不仅仅是我一开始就告诉它存储的“无模式”数据的性质，而是有兴趣听听想法。
这仅仅是一个“非问题”吗？
问问题
43 次
1 回答
2
首先，免责声明：数据建模很难。有许多细微差别，一个 SO 问题永远无法涵盖整个业务，并且在 Q 和 A 中都未提及所有内容。没有灵丹妙药。不管..
“轻客”
在您的客户端代码中拥有这样的模型非常好。您的主要客户模型可能并且将会有许多表示，其中大多数是完整模型的简单子集。与关系 sql 类似，只选择您需要的。不要将不需要的数据提取给客户端。
SQL API提供了非常酷的SQL 工具来为您编写返回文档的 json。
物理存储模型可能与域模型不同
考虑您的使用场景。如果许多场景碰巧与没有小部件的客户一起工作（反之亦然），那么考虑将小部件作为存储模型中的单独文档。
在 DocDB 中，问题通常不在于查询逻辑，而在于您的应用程序对修改逻辑的期望。被索引的查询速度很快，每个 sql 查询都可以轻松进行转换（尽管跨文档连接很麻烦）。对于 C(R)UD - 你有更少的选择 - 它总是通过完整的文档。拥有太大的文档最终会导致更高的 RU 成本和复杂的代码。
需要考虑的问题：
- 在小部件数量/细节不改变的情况下，客户多久更换一次？
- 在客户不改变的情况下，小部件多久更换一次？
- 客户上的小部件是独立更改还是始终作为一组更改？
- 您何时需要有关客户+小部件更改的事务更新？
- 查询会是什么样子？它们可以被索引吗？
测试。
诚然，稍后更改模型在 DocDB 中很麻烦，但在您知道它已损坏之前不要尝试修复它。如果你不确定你是否有问题，那么修复可能的问题很可能比不修复它更昂贵。
如果有疑问，请生成大量数据并进行测试。
于 2018-06-12T12:13:29.760 回答