title: DynamoDB: Duplicate a bunch of data to save a second lookup?
body: <p>There are two typical uses for my database.</p>
  <ol>
  <li>A user will access their record/item via their userID, and they will manage their info and a number of devices, each with a unique devID.</li>
  <li>A device connects and using its devID, will find the owning userID, then takes action based on attributes in the user item.</li>
  </ol>
  <p>Two options I could use, each with a single DynamoDB table.</p>
  <p>A. The table has items that are users and devices, with a partition key of ID and sort key of itemType. User items have associated attributes like addresses, account and profile info, etc. Devices have associated attributes like their preferences, their type, their capabilities.</p>
  <p>You can access both users and devices really quickly. If you are doing (1) you lookup and find a user, then you will have to use a set attribute that lists the one or more deviceIDs it owns, and then make individual lookups for each device. That's 2 lookups for a user that owns one device and more for multiple devices.
  Or if you are doing (2), search and find a device, you grab its userID attribute and then lookup the userID item. That's 2 lookups.</p>
  <p>B. I could reduce the multiple lookups this way:
  Still one table, but all entries in the table are more homogenous: Every item includes all user related attributes, and includes one device's attributes. The provisioning key is the userID and sort key is deviceID, another indexed attribute is just the deviceID. If you are doing (1) then you lookup the userID and you get one or more records depending on whether they own one device or more. If you are doing (2), then we quickly find the device, and that same item includes all the user info we need and we don't need to do another lookup.</p>
  <p>The problem with B is that I am duplicating a lot of data about the user in each of the items. Keeping them all synced is going to be problematic too, but that's a lot rarer.</p>
  <p>So, am I overthinking the lookup costs, and should just go with the multiple lookup as in A, or is the multiple lookups going to be expensive enough that I need to have a better data design?</p>