title: How does nesting structures affect DocumentDB query performance?
body: <p>The question might otherwise be stated as "to flatten or not to flatten?"</p>
  
  <p>If I were to store nested JSON documents in a DocumentDB collection, would querying across those nested structures perform on par with having stored those nested structures in a separate collection as flat documents on their own?</p>
  
  <p>The data in question will be written once and (likely) never updated.  Reporting performance is at the top of the requirements list.</p>
  
  <p>On one hand, storing the data in a nested structure seems like the "correct" way to make use of the no-schema / no SQL technology.  That is, we naturally want to associate header data with detail data all in one place and in context.  But can it scale and continue to perform once we're writing thousands of rows a minute while simultaneously running reports on that collection from a web application?</p>
  
  <p>Or, would it be better to flatten out that detail data, redundantly storing relevant parts of the header data in each row of the detail collection?  As a long-time RDBMS developer / user, I tend to want to not store data redundantly, but should I let go of that idea in favor of high performance?</p>
  
  <p>Does a flat data structure query more efficiently in DocumentDB and by how much of a margin?  That is, what am I giving up by doing that, and is it worth it if performance is a top (but not the only) priority?</p>