title: In CouchDB, should I use the _id for relation and _changes?
body: <p>I've been <a href="https://glynnbird.com" rel="nofollow noreferrer">reading a lot</a> of <a href="https://github.com/jo/couchdb-best-practices" rel="nofollow noreferrer">best practices</a> and how I should <a href="https://github.com/jo/couchdb-best-practices#embrace-the-document-id" rel="nofollow noreferrer">embrace the _id</a>. To be honest, I'm getting my kind of paranoid at the repercussions I might face if I don't do this for when I start scaling up my application. </p>
  
  <p>Currently I have about 50k documents per database. It's only been a few months with heavy usage. I expect this to grow A LOT. I do a lot of <code>.find()</code> Mango Queries, not much indexing; and to be honest working off a relational style document structuring. </p>
  
  <p>For example:</p>
  
  <ul>
  <li>First get Project from ID.</li>
  <li>Then do a find query that:
  
  <ul>
  <li>grabs all <code>type:signature</code> where <code>project_id: X</code>.</li>
  <li>grabs all <code>type:revisions</code> where <code>project_id: X</code>.</li>
  </ul></li>
  </ul>
  
  <p>The reason for this is I try VERY hard not to update documents. A lot of these documents are created offline, so doing a write once workflow is very important for me to avoid conflicts.</p>
  
  <p>I'm currently at a point of no return as scheduling is getting pretty intense. If I want to change the way I'm doing things now is the best time before it gets too crazy.</p>
  
  <p>I'd love to hear your thoughts about using the <code>_id</code> for data structuring and what people think.</p>
  
  <p>Being able to make one call with a _all_docs grab like this sounds appealing to me:</p>
  
  <pre><code>{
    "include_docs": true,
    "startkey": "project:{ID}",
    "endkey": "project:{ID}:\ufff0"
  }
  </code></pre>
  
  <p>An example of how ONE type of my documents are set is like so:</p>
  
  <p><strong>Main Document</strong></p>
  
  <pre><code>{
      _id: {COUCH_GENERATED_1},
      type: "project",
      ..
      .
  }
  </code></pre>
  
  <p><strong>Signature Document</strong></p>
  
  <pre><code>{
      _id: {COUCH_GENERATED_2},
      type: "signature",
      project_id: {COUCH_GENERATED_1},
      created_at: {UNIX_TIMESTAMP}
  }
  </code></pre>
  
  <p><strong>Change to Main Document</strong></p>
  
  <pre><code>{
      _id: {COUCH_GENERATED_3},
      type: "revision",
      project_id: {COUCH_GENERATED_1},
      created_at: {UNIX_TIMESTAMP}
      data: [{..}]
  }
  </code></pre>
  
  <hr>
  
  <p>I was wondering whether I should do something like this:</p>
  
  <p><strong>Main Document</strong>: <code>_id: project:{kuuid_1}</code></p>
  
  <p><strong>Signature Document</strong>: <code>_id: project:{kuuid_1}:signature:{kuuid_2}</code></p>
  
  <p><strong>Change to Main Document</strong>: <code>_id: project:{kuuid_1}:rev:{kuuid_3}</code></p>
  
  <p>I'm just trying to set up my database in a way that isn't going to mess with me in the future. I know problems are going to come up but I'd like not to heavily change the structure if I can avoid it.</p>
  
  <p>Another reason I am thinking of this is that I watch for <code>_changes</code> in my databases and being able to know what types are coming through without getting each document every time a document changes sound appealing also.</p>