One-to-many relationship patterns in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Querying all orders for a single customer

You have a DynamoDB table named Orders with a partition key CustomerID and a sort key OrderID. Which query will return all orders for customer with ID 123?

A Query with KeyConditionExpression: OrderID = '123'

B Scan with FilterExpression: CustomerID = '123'

C Scan with FilterExpression: OrderID = '123'

D Query with KeyConditionExpression: CustomerID = '123'

💡 Hint

Remember, queries use the partition key to efficiently find items.

Querying with CustomerID = '123' uses the partition key to get all orders for that customer efficiently. Scans are less efficient and filtering on sort key alone won't work.

❓ schema

intermediate

Designing a one-to-many pattern with composite keys

You want to store blog posts and their comments in one DynamoDB table. Each post has many comments. Which key design best supports efficient retrieval of all comments for a post?

A Partition key: PostID, Sort key: CommentID

B Partition key: CommentID, Sort key: PostID

C Partition key: PostID, Sort key: PostID

D Partition key: CommentID only

💡 Hint

Think about grouping comments under the post they belong to.

Using PostID as partition key groups all comments for that post together. CommentID as sort key uniquely identifies each comment.

❓ optimization

advanced

Optimizing queries for recent comments retrieval

You want to get the 5 most recent comments for a post. Comments have a Timestamp attribute. How should you design the sort key to optimize this query?

A Sort key: Timestamp (descending order)

B Sort key: Timestamp (ascending order)

C Sort key: CommentID

D Sort key: PostID

💡 Hint

DynamoDB sort keys are stored in ascending order by default.

Using Timestamp as sort key in ascending order allows querying with ScanIndexForward=false to get recent comments first.

🔧 Debug

advanced

Why does this query return no results?

You run this DynamoDB query to get comments for post p1:

KeyConditionExpression: "PostID = :pid AND CommentID > :cid"
ExpressionAttributeValues: {":pid": "p1", ":cid": "c0"}

But it returns no items, even though comments exist. What is the likely cause?

A ExpressionAttributeValues syntax is wrong

B PostID value is incorrect

C CommentID is not the sort key, so condition on it fails

D KeyConditionExpression cannot use > operator

💡 Hint

KeyConditionExpression conditions apply only to partition and sort keys.

Conditions on attributes that are not partition or sort keys in KeyConditionExpression cause no results. CommentID must be the sort key to use > operator.

🧠 Conceptual

expert

Modeling many comments per post with single table design

You want to store posts and their comments in one DynamoDB table using a single table design. Which pattern correctly models the one-to-many relationship?

A Use partition key as PostID, sort key as 'POST#' for posts and 'COMMENT#CommentID' for comments

B Use partition key as CommentID, sort key as PostID

C Use partition key as PostID only for posts and separate table for comments

D Use partition key as CommentID, sort key as 'POST#PostID'

💡 Hint

Single table design uses composite sort keys to distinguish item types.

Using PostID as partition key groups all items for a post. Sort key prefixes like 'POST#' and 'COMMENT#' distinguish posts from comments and allow querying all related items.

Practice

1. What is the main purpose of using a PartitionKey in a one-to-many relationship pattern in DynamoDB?

easy

A. To group all related items under one main item

B. To uniquely identify each related item

C. To store the data type of the item

D. To define the size of the table

Solution

1. Step 1: Understand PartitionKey role

   The PartitionKey groups related items together in DynamoDB, acting like a folder for related data.

2. Step 2: Differentiate PartitionKey from SortKey

   The SortKey uniquely identifies each item within the group, but PartitionKey groups them all.

3. Final Answer:

   To group all related items under one main item -> Option A

4. Quick Check:

   PartitionKey groups related items = D [OK]

Hint: PartitionKey groups items; SortKey identifies each item [OK]

Common Mistakes:

• Confusing PartitionKey with SortKey
• Thinking PartitionKey uniquely identifies each item
• Assuming PartitionKey stores data type

2. Which of the following is the correct way to define a SortKey in a DynamoDB table for a one-to-many relationship?

easy

A. SortKey as the PartitionKey

B. SortKey as the same value for all items

C. SortKey as a unique identifier for each related item

D. SortKey as the table name

Solution

1. Step 1: Understand SortKey purpose

   The SortKey uniquely identifies each related item within the same PartitionKey group.

2. Step 2: Eliminate incorrect options

   SortKey cannot be the same for all items or equal to PartitionKey or table name.

3. Final Answer:

   SortKey as a unique identifier for each related item -> Option C

4. Quick Check:

   SortKey uniquely identifies items = C [OK]

Hint: SortKey uniquely identifies related items within a PartitionKey [OK]

Common Mistakes:

• Using same SortKey for all items
• Confusing SortKey with PartitionKey
• Assigning table name as SortKey

3. Given a DynamoDB table with PartitionKey = 'CustomerID' and SortKey = 'OrderID', what will the query Query(CustomerID='123') return?

medium

A. Only the order with OrderID 123

B. All orders for customer with ID 123

C. All customers with OrderID 123

D. An error because SortKey is missing

Solution

1. Step 1: Understand Query with PartitionKey only

   Querying with PartitionKey='123' returns all items sharing that PartitionKey, i.e., all orders for customer 123.

2. Step 2: Clarify SortKey role in query

   SortKey is not specified, so all SortKey values under PartitionKey='123' are returned.

3. Final Answer:

   All orders for customer with ID 123 -> Option B

4. Quick Check:

   Query by PartitionKey returns all related items = A [OK]

Hint: Query by PartitionKey returns all related items [OK]

Common Mistakes:

• Thinking query returns single item without SortKey
• Confusing PartitionKey and SortKey in query
• Expecting error when SortKey is not specified

4. You have a DynamoDB table with PartitionKey = 'PostID' and SortKey = 'CommentID'. You try to insert two comments with the same PostID and CommentID. What is the issue?

medium

A. The second insert overwrites the first comment

B. Both comments are stored separately

C. DynamoDB throws a syntax error

D. PartitionKey must be unique, so insert fails

Solution

1. Step 1: Understand uniqueness of PartitionKey + SortKey

   In DynamoDB, the combination of PartitionKey and SortKey must be unique for each item.

2. Step 2: Analyze inserting duplicate keys

   Inserting an item with the same PartitionKey and SortKey overwrites the existing item.

3. Final Answer:

   The second insert overwrites the first comment -> Option A

4. Quick Check:

   Duplicate keys overwrite existing item = A [OK]

Hint: Duplicate PartitionKey+SortKey overwrites existing item [OK]

Common Mistakes:

• Expecting error on duplicate keys
• Thinking both items are stored separately
• Confusing PartitionKey uniqueness with SortKey

5. You want to model a one-to-many relationship where each customer can have multiple orders, and each order can have multiple items. Which DynamoDB design pattern best fits this scenario?

hard

A. Use PartitionKey as CustomerID and SortKey as OrderID#ItemID

B. Use PartitionKey as OrderID and SortKey as CustomerID#ItemID

C. Use PartitionKey as ItemID and SortKey as CustomerID#OrderID

D. Use PartitionKey as CustomerID#OrderID and SortKey as ItemID

Solution

1. Step 1: Understand the hierarchy

   Customer has many orders, and each order has many items, so two levels of one-to-many.

2. Step 2: Design composite keys for nested relationships

   Using PartitionKey as CustomerID#OrderID groups items by order under each customer; SortKey as ItemID identifies each item.

3. Step 3: Eliminate other options

   Other options mix keys incorrectly, losing the hierarchical grouping.

4. Final Answer:

   Use PartitionKey as CustomerID#OrderID and SortKey as ItemID -> Option D

5. Quick Check:

   Composite PartitionKey groups nested one-to-many = B [OK]

Hint: Use composite PartitionKey for nested one-to-many groups [OK]

Common Mistakes:

• Using wrong key order losing hierarchy
• Not combining keys for nested relationships
• Confusing PartitionKey and SortKey roles