title: Structuring DynamoDB tables vs traditional relational model
body: <p>I'm trying to wrap my head around DynamoDB's scans and queries, and how I should structure my tables.</p>
  
  <p>Let's say I have buckets and marbles, and each bucket can contain many marbles. In a traditional relational database, I might set that up like this:</p>
  
  <h2>Buckets</h2>
  
  <pre><code>id  name  
  ---------------
  B1  Blue Bucket
  B2  Red Bucket
  </code></pre>
  
  <h2>Marbles</h2>
  
  <pre><code>id  name           bucketId  lots more fields...
  ------------------------------------------------
  M1  Deep Swirls    B1
  M2  Fire Red       B1
  M3  Obsidian       B2
  </code></pre>
  
  <p>As I understand it, if I structured my data this way in DynamoDB, it could be costly for RCUs because I'd have to do scans. If I wanted to get all the marbles in bucket B1, I'd have to do a scan of <code>Marbles</code> where <code>bucketId = B1</code>, which grabs the full list of marbles and then removes the ones that don't match (if I understand the inner workings of DynamoDB correctly).</p>
  
  <p>This doesn't sound very performant or cost-effective. How should I structure this data?</p>
  
  <p><strong>IMPORTANT NOTE:</strong> Marbles should be able to exist on their own, i.e. part of no bucket. (<code>bucketId = null</code>)</p>