建模文档数据和查询性能

Question

我有一个aggerate数据模型（将具有属于它们的Widgets的Customer实体视为嵌入实体列表）。

当我搜索客户时（例如DocumentDBRepository.GetItemsAsync）这将为客户数据模型以及每个客户端的小部件提供保湿。出于效率原因，我并不需要客户搜索来考虑小部件。

文档dbs中是否有任何策略（例如“LiteCustomer”实体）？我怀疑不是因为这只是我首先告诉它存储的“无模式”数据的本质，但有兴趣听到想法。

这只是一个'非问题'吗？

Answer 1

首先，免责声明：数据建模很难。有很多细微差别，SO问题永远不能涵盖整个业务，Q和A都没有说明。没有银子弹。无论..

“LiteCustomer”

在您的客户端代码中拥有此类模型非常好。您的主要客户模型可能并且将具有许多表示，其中大多数是完整模型的简单子集。与关系型sql类似，仅选择您需要的内容。不要将数据提取到您不需要的客户端。

SQL API提供了非常酷的SQL工具来为你编写返回文档的json。

物理存储模型可能与域模型不同

考虑您的使用方案。如果许多场景碰巧与没有小部件的客户合作（反之亦然），那么会将小部件视为存储模型中的单独文档。

在DocDB中，问题往往不是查询逻辑，而是应用程序对修改逻辑的期望。查询索引的速度很快，每个sql查询都可以轻松进行转换（尽管跨文档连接很麻烦）。对于C（R）UD - 你有更少的选择 - 它总是由完整的文件。文档太大会导致更高的RU成本和复杂的代码。

要考虑的问题：

• 客户在没有小部件数量/细节变化的情况下更改的频率？
• 小部件在没有客户更改的情况下更改的频率如何？
• 客户的小部件是独立更改还是始终作为一组更改？
• 您何时需要有关客户+窗口小部件更改的交易更新？
• 查询会如何？它们可以编入索引吗？

测试。

确实，稍后更改模型在DocDB中很麻烦，但在你知道它被破坏之前不要尝试修复它。如果您不确定是否有问题，那么很可能修复可能问题比修复问题更昂贵。

如果有疑问，请生成大量数据并对其进行测试。