A city case-management app must fetch a case by caseId and also list a citizen’s cases by citizenId plus filing date. Why is a single partition key alone a poor fit?
Select an answer to reveal the explanation.
Short Explanation
Picture two different filing cabinets for the same stack of case folders. One lookup is “give me this case number”; the other is “give me everything this citizen filed last month.” One partition key alone can’t serve both efficiently—you design the base table for one pattern and add a GSI (or careful composite keys) for the other.
Full Explanation
DynamoDB access patterns drive key design. Fetch-by-caseId wants a high-cardinality partition key on caseId (often with a sort key for related entities). List-by-citizenId with a date range wants citizenId as the partition key and a date (or caseId) as the sort key. A single primary key cannot optimize both; the usual pattern is a base table for the primary pattern plus a global secondary index for the alternate query. RDS foreign keys and “DynamoDB forbids attributes” are misconceptions.