title: Alternative to nested documents in Firestore - looking for best practices?
body: <p>I have some concerns about the structure for a Firestore-based project, since directly nesting documents don't seem to be an option.</p>
  
  <p>To keep things simple, let's say we have a firestore DB containing data about football matches. For each match, there's a document with the player lineup, a document with a list of match events, a document with match statistics etc.</p>
  
  <p>Since things like statistics, events and lineups are updated at different intervals, imported from different API calls and used in separate screens in the consuming app, I guess it's smartest to to keep them in separate documents.</p>
  
  <p>I'm currently using a structure like this:</p>
  
  <pre><code>/app-data/match-lineup/matches/123456
  /app-data/match-events/matches/123456
  /app-data/match-statistics/matches/123456
  </code></pre>
  
  <p>And I then refer to it like this:</p>
  
  <pre class="lang-js prettyprint-override"><code>      db.collection("app-data")
        .doc("match-lineups")
        .collection("matches")
        .doc(id);
  </code></pre>
  
  <p>But as I add more different documents related to a match, I start getting concerns whether the current structure is an anti-pattern.</p>
  
  <p>What I would prefer was a structure like this, which I find most elegant and similar to a REST URL.</p>
  
  <pre><code>/matches/123456/lineup
  </code></pre>
  
  <p>But that's not an option since the <code>123456</code> cannot refer to a <code>lineup</code> document.</p>
  
  <p>A workaround could be something like </p>
  
  <pre><code>/matches/123456/attributes/lineup
  </code></pre>
  
  <p>With a reference like this</p>
  
  <pre class="lang-js prettyprint-override"><code>      db.collection("matches")
        .doc(id);
        .collection("attributes")
        .doc("lineup")
  </code></pre>
  
  <p>Is this the best compromise, or are there other options that should be considered?</p>