否则，这个问题可能被称为“压扁或不压扁？”
如果我要将嵌套的JSON文档存储在DocumentDB集合中，那么查询这些嵌套结构是否与将这些嵌套结构作为平面文档存储在单独的集合中相同？
有问题的数据将被写入一次并且（可能）永远不会更新 . 报告性能位于需求列表的顶部 .
一方面，将数据存储在嵌套结构中似乎是使用无架构/无SQL技术的“正确”方法 . 也就是说，我们自然希望在一个地方和上下文中将 Headers 数据与详细数据相关联 . 但是，一旦我们每分钟写入数千行，同时从Web应用程序运行该集合的报告，它是否可以扩展并继续执行？
或者，是否更好地将详细数据展平，在 Headers 集的每一行中冗余地存储 Headers 数据的相关部分？作为一个长期的RDBMS开发人员/用户，我倾向于不想冗余地存储数据，但是我应该放弃这个想法以支持高性能吗？
平面数据结构是否在DocumentDB中更有效地查询以及有多少余量？也就是说，通过这样做我放弃了什么，如果性能是最重要的（但不是唯一的）优先级，它是否值得呢？
1 回答
对此没有一个“正确”的答案 .
选择是否将关系表示为单个嵌入式文档（也称为反规范化）或者像在RDBMS中那样表示引用（也称为规范化）在很大程度上取决于您的用例/场景 .
通常，您需要针对读取繁重的方案进行反规范化，并针对写入较多的方案进行规范化 .
DocumentDB团队刚刚发布了一份关于此的参考文档;我建议给它一个读：http://azure.microsoft.com/en-us/documentation/articles/documentdb-modeling-data/