Storing different document types in one DocumentDb collection

Question

We have a multitenant application that uses Azure DocumentDB as our NoSQL document oriented database.

For multitenancy, we read this question and this blog post. Because right now our number of users do not meet the need to use different databases and/or documentCollections, and more importantly, for cost savings we implemented multitenancy with a "Where" clause on a TenantId field with one documentCollection.

Similarly, when it comes to storing "documents" or "objects" with complete different natures (say for example Book and Car) we are questioning ourselves on the fact to use one documentCollection.

At first, it looks more reasonable to create two different documentCollection for Book and Car. However, creating a documentCollection costs 25$ minimum. We do not want to pay +25$ everytime we need to add a new feature even if it is to store a low amount of data (e.g. our app stores a lot of Books but few Cars...).

Is it a good design to put Book and Car in the same documentCollection? And keep a reference to the type of the document in a shared member (e.g. string Type ="Book" or string Type = "Car").

Knowing that we have already implemented the Multitenancy with a Where "clause", to query all Cars in our App for a given tenant, our queries would all contain Where TenantId ="XXXX" AND Type = "Car".

I have seen that DocumentDB supports now the Partitioned Collection. Could this be a good usage of the partitions or, on the contrary, they should be kept to achieve better scalability and are not adapted to segregate different document types whose object quantities may not be similar?

Answer 1

Yes, it is "good design" to use type="Book". You can also do isBook=true, which I believe is slightly more efficient and enables inheritance and mixin behavior.

Partitioned Collections are actually a way to put more stuff into a single larger entity rather than the other way around. The idea is to allow scaling of both throughput (RUs) and space without the burden of managing multiple Collections yourself. You "could" make your partition key be your type field, but I would not recommend it. Partition keys should enable roughly even spread among partitions... among other criteria.