DynamoDB schema design
https://www.youtube.com/watch?v=p8phVh6HRkQ
You can play around on DynamoDB for free by using NoSQL workbench for DynamoDB.
Philosophy
- Thou shall use one or fewer tables
- Thou shall know there are no JOINs
- Thou shall use a PK and an optional SK (sort key)
- Thou shall use GSIs (global secondary indexes) to group different columns and will not spam GSIs to incur more costs
Patterns
Do nothing

This is bad because, you make more requests than what is nessisary.
Denormalise with JOIN

- It is fast
- Data will be duplicated, so more space taken up and more points to change when changing one data point
Stacked with UNION

Stack all normalised relational tables into one dynamoDB table
Note: that the PK will start with what data it contains, ‘cust-123’ will define customer data
- Fast
- No duplication
GSIs will be used to group rows
Note: using this costs more, so use less often
Note: there is no optimiser to use the GSI for you

Date formats (only talking about it cos its not a type)

(first is a string, second is a number)
These two formats are recommend because they are sortable.
String:
- Better for readability
Int:
- Better for storage
- Can use a TTL, rows can be removed after a certain amount of time
GSI
A Global Secondary Index (GSI) in DynamoDB is an index that has a partition key and an optional sort key that can be different from those on the base table. This allows for more flexible querying, including the ability to query on any attribute (not just the primary key attributes), and allows for faster access to data.
Best practice:
- Use them sparingly, because they cost money to maintain and also take up more storage
- Typically used to group data
- If only a few rows have a certain column, then GCIs can be good to grab only them columns, by going down the index table and getting all of them, instead of doing a global search
- I think some rows can be ignored and not added to the GSI
- Dont bother using Local Secondary Index because it is not as flexible as GSI
Do not assume:
- DynamoDB has an optimiser, because it wont just use an index without your say