"If you don't know where you are going, any road will get you there.

" (Lewis Carroll)

Tenets of DynamoDB data modelling

1. Understand the use case.
- Nature of the data
- Entity relationships
- Concurrency
- Archiving and recovery needs

2. Identify the access patterns

- Read/Write workloads
- Query dimensions and aggregations
- Which ones are “hot paths” – highest frequency queries?

3. Data modeling
- Use NoSQL design patterns
- 1:1, 1:n, m:n relationships
- 1 application = 1 table
- Identify primary key
- Partition key and Sort key
- Query dimensions using LSIs and GSIs

4. Review -> Repeat -> Review

Single vs Multi table design

The first step in designing your DynamoDB application is to identify the specific query
patterns that the system must satisfy.

The data-modelling guidance to use one table is rather confusing. I assume the intent is to
encourage denormalization so data that tends to be read or written together can fit into one
item. But I could see it being misinterpreted as encouraging developers to force-fit
everything into one table. For example, a trivial e-commerce application might have
customers and orders. It would be natural to have a customer table and an orders table. But
it's easy to misread this guidance and think that there should be a single "entities" table
containing both customers and orders. I would consider that a bad practice.

Thinks about these questions to help you decide whether you want a single table or
multiple:
- Do I need to access some customer details along with order info most of the time?
- Will having separate tables lead to doing joins at the application level? – If this is
done more frequently, then your application has turned into a database here.
- Do you want to split out behaviours/mechanisms that are configured per table? -
Maybe you only want to see changes for some of your items in your DynamoDB
stream. Maybe you only want to back up some of your items.
- Single table design is not easy. Is developer agility more than important than
application performance? – You need to weight benefits vs costs.
Without taking sides in this religious war of single vs multiple table design, I think we have to
let the access patterns and use cases decide. The main reason for using a single table in
DynamoDB is to retrieve multiple, heterogenous item types using a single request.