title: Storing different document types in one DocumentDb collection
body: <p>We have a multitenant application that uses Azure DocumentDB as our NoSQL document oriented database.</p>
  
  <p>For multitenancy, we read <a href="https://stackoverflow.com/questions/29838197/azure-documentdb-multi-tenant-architecture">this question</a> and <a href="https://azure.microsoft.com/en-gb/blog/scaling-a-multi-tenant-application-with-azure-documentdb-2/" rel="noreferrer">this blog post</a>. Because right now our number of users do not meet the need to use different databases and/or <code>documentCollections</code>, and more importantly, for cost savings we implemented multitenancy with a "Where" clause on a TenantId field with one <code>documentCollection</code>.</p>
  
  <p>Similarly, when it comes to storing "documents" or "objects" with complete different natures (say for example <code>Book</code> and <code>Car</code>) we are questioning ourselves on the fact to use one <code>documentCollection</code>. </p>
  
  <p>At first, it looks more reasonable to create two different <code>documentCollection</code> for <code>Book</code> and <code>Car</code>. However, creating a <code>documentCollection</code> 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 <code>Books</code> but few <code>Cars</code>...).</p>
  
  <p>Is it a good design to put Book and Car in the same <code>documentCollection</code>? And keep a reference to the type of the document in a shared member (e.g. <code>string Type ="Book" or string Type = "Car"</code>).</p>
  
  <p>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 <code>Where TenantId ="XXXX" AND Type = "Car"</code>.</p>
  
  <p>I have seen that DocumentDB supports now the <a href="https://azure.microsoft.com/en-us/documentation/articles/documentdb-partition-data/" rel="noreferrer">Partitioned Collection</a>. 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?</p>