The DyanmoDB best practices make it clear that:
You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.
I find it amusing then that just about every single tutorial I've seen dealing with DyanmoDB has a multi-table design.
But what does this mean in practice?
Let's consider a simple application with three main entities: Users, Projects, and Documents. A User owns multiple projects, and a Project can have multiple Documents. We typically have to query on the Projects for a User, and on the Documents for a Project. Reads outnumber writes by a significant margin.
A naive tutorial's table design would use three tables:
Users Hash key user-id Projects Hash key Global Index project-id user-id Documents Hash key Global Index document-id project-id
We could pretty easily collapse
Document into one
Documents Hash key Sort key Global Index project-id document-id user-id
But why stop there? Why not one table to rule them all? Since the
User is the root of everything...
Users Hash key Sort key user-id aspect --------- --------- foo user email: email@example.com ... foo project:1 title: "The Foo Project" foo project:1:document:2 document-id: 2 ...
Then we would have a Global Index on, say, the
document-id field for direct document lookups.
Is that how it's supposed to work? Is it legit to throw such wildly-divergent kinds of data into the same table? Or is the second, two-table design a better approach?
At what point would it be correct to add a second table?