由于Microsoft选择为每个DocumentDB集合设置至少400RU，因此它们的定价结构指导开发人员根据RU要求创建集合，而不是一组代表逻辑数据模型的集合 . 即，可以创建一组需要高查询成本/吞吐量（1000RU），中等（600RU）和低RU（400RU）的集合 . 这些集合中的每一个都可以包含多种类型的实体 .
但是，基于集合的索引似乎会妨碍这种方法 . 如果实体A和实体B存储在同一集合中并且都包含“名称”属性，则额外的索引可能对这两个实体都没有益处 . 我不清楚如何解决这个限制 .
可以为每种类型的文档创建一个集合，该集合需要任何额外的索引，但这也会产生浪费 . 我可能会创建不代表预计支出的集合 .
有没有更好的方法来使用DocumentDB索引文档？
1 回答
DocumentDB is schemaless ，我想说能够插入具有任何模式的文档，并且具有与之抗争的一点点的索引 .
该设计允许您拥有尽可能多（或几个）的集合，因为您认为这些集合是性能/维护/数据组织需求的最佳选择 . 如果您认为额外的成本是合理的，您可以从一个集合无缝地开始并将N种类型转移到另一个集合 . 所以 you CAN build a "set of collections that represent a logical data model" 如果你愿意支付所提供的额外RU 's - having a single pool from which to handle peaks is usually cheaper than N smaller ones, so by splitting you have to overprovision more to be safe. But it'你的选择 .
关于索引 - 如果需要存储具有相同属性名称的2个实体，则 design your model so they'd have different path ，因此可以在查询和索引中进行区分 . 对于关系数据库思维模式，IT确实有意义：不要在同一数据字段中存储不同的事实 . 从技术上讲，你可以做到这一点，但它通常会很快回来 .
拥有 differently named parent container for each "type" 是区分类型的最简单且相当未来的方法，因为它允许您在集合之间添加或转移"types"并仍然避免索引冲突 . 另一方面，请确保将"cross-type"字段保留在统一索引的统一位置，例如审计字段或全局唯一键 .
与往常一样，数据设计决定了您能做什么或不能做什么 .