Scribd
Upload
75 views2 pages

Single Multi Table

The document discusses data modeling best practices for DynamoDB, including understanding use cases, access patterns, relationships, and query dimensions. It cautions that while DynamoDB guidance recommends a single table design, multiple tables may be better for some applications to avoid joins and enable splitting behaviors. The conclusion is that the access patterns and use cases should determine whether a single or multiple table design is most appropriate.

Uploaded by

sunil kalva
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
75 views2 pages

Single Multi Table

The document discusses data modeling best practices for DynamoDB, including understanding use cases, access patterns, relationships, and query dimensions. It cautions that while DynamoDB guidance recommends a single table design, multiple tables may be better for some applications to avoid joins and enable splitting behaviors. The conclusion is that the access patterns and use cases should determine whether a single or multiple table design is most appropriate.

Uploaded by

sunil kalva
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

"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.

You might also like