我们有一个 Multi-Tenancy 应用程序，它使用 Azure DocumentDB 作为面向 NoSQL 文档的数据库。
对于 Multi-Tenancy ，我们阅读 this question和 this blog post 。因为目前我们的用户数量无法满足使用不同数据库和/或 documentCollections 的需求，更重要的是，为了节省成本，我们在 TenantId 字段上使用“Where”子句实现了 Multi-Tenancy ，其中包含一个文档集合。
同样，当涉及存储性质完全不同的“文档”或“对象”(例如 Book 和 Car)时，我们会质疑自己的事实使用一个documentCollection。
首先，为 Book 和 Car 创建两个不同的 documentCollection 看起来更合理。但是，创建 documentCollection 最低成本为 25 美元。我们不想每次需要添加新功能时都支付 +25 美元，即使它要存储少量数据(例如，我们的应用程序存储大量 Books 但很少 Cars ...)。
将Book和Car放在同一个documentCollection中是一个好的设计吗？并在共享成员中保留对文档类型的引用(例如，string Type ="Book"或 string Type = "Car")。
知道我们已经使用Where“子句”实现了 Multi-Tenancy ，为了查询应用程序中给定租户的所有汽车，我们的查询都将包含 Where TenantId ="XXXX"AND Type = "Car".
我发现 DocumentDB 现在支持 Partitioned Collection 。这是否是分区的一个很好的用途，或者相反，应该保留它们以实现更好的可扩展性，并且不适合隔离对象数量可能不相似的不同文档类型？
最佳答案
是的，使用type="Book"是“好的设计”。您还可以执行 isBook=true，我认为这稍微更有效并且支持继承和混合行为。
分区集合实际上是一种将更多内容放入单个更大实体中的方法，而不是相反。这个想法是允许扩展吞吐量(RU)和空间，而无需自己管理多个集合的负担。您“可以”将分区键设置为 type 字段，但我不建议这样做。分区键应该能够在分区之间大致均匀分布......以及其他标准。
关于azure - 在一个 DocumentDb 集合中存储不同的文档类型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36749456/