由于Microsoft选择为每个DocumentDB集合设置至少400RU，因此它们的定价结构指导开发人员根据RU要求创建集合，而不是一组代表逻辑数据模型的集合。 即，可以创建一组需要高查询成本/吞吐量（1000RU），中等（600RU）和低RU（400RU）的集合。每个集合都可以包含多种类型的实体。
但是，基于集合的索引似乎会妨碍这种方法。如果实体A和实体B存储在同一集合中并且都包含“名称”属性，则额外的索引可能对这两个实体都不利。我不清楚如何解决这个限制。
可以为每种类型的文档创建一个集合，该集合需要任何额外的索引，但这也会产生浪费。我可能会创建不代表预计支出的集合。
使用DocumentDB索引文档是否有更好的方法？
答案 0 :(得分：1)
DocumentDB是无模式的，我想说能够插入任何模式的文档，并且索引不关心文档＆＃34; type＆＃34;在同一系列中，非常有意的设计。打击它有点意思。
该设计允许您拥有尽可能多（或几个）的集合，因为您认为这些集合是性能/维护/数据组织需求的最佳选择。如果您认为额外的成本是合理的，您可以从一个集合无缝地开始并将N种类型转移到另一个集合。所以你可以构建一组代表逻辑数据模型的集合＆＃34; 如果你愿意为所配置的额外RU付费 - 有一个单独的池从中处理峰值通常比N个较小的峰值便宜，因此通过拆分你必须过度配置更安全。但这是你的选择。
关于索引 - 如果您需要存储具有相同属性名称的2个实体，那么设计您的模型，以便它们具有不同的路径，因此可以在查询和索引中进行区分。 IT确实对关系数据库思维也有意义：不要在同一数据字段中存储不同的事实。从技术上讲，你可以做到这一点，但它通常会很快回来。
为每个＆＃34;类型＆＃34; 设置不同名称的父容器是区分类型的最简单且更具未来发展方式，因为它允许您添加或转移＆＃34;类型＆＃ 34;收集之间仍然避免索引冲突。另一方面，请确保保持＆＃34;交叉类型＆＃34;统一索引的统一位置字段，例如审计字段或全局唯一键。
与往常一样，数据设计决定了您能做什么或不能做什么。