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