A different key for a different question
A secondary index re-keys your items so you can Query them on a new axis.
Why
The base table groups tickets by project. But 'every ticket assigned to Ada, across all projects' needs a different partition key, and you cannot change the table's keys.
A global secondary index is the answer: it is an automatically-maintained, re-keyed copy of your items. Query the base table for a project; Query the index for an assignee. Same items, two axes.
An index is a re-keyed copy of your data. Add one when an access pattern needs a key the table does not have.
Try it. Then change it.
Predict what each request will do. Run it, inspect the response, then change a value in the workbench and try again.
The base table is keyed by project, so 'this project's tickets' is a Query on the table.
'Everything assigned to Ada' crosses projects, so the table's keys can't answer it, but the by-assignee index can.
Built on this
- URL Shortener - Where does this short link go?
- Web Sessions - Who owns this session?
- Change & Audit Log - What happened, and when?
- Support Ticket Queue - Which ticket should we pick up next?
- Store Locator - Which stores are nearby?
- Geospatial Nearest Neighbour - Which store is actually nearest?
- Contacts CRM - How do I find this contact?
- Game Leaderboard - Who’s at the top?
- Maintainers & Projects - Who maintains this project?
- Catalogue Semantic Search - What’s like this, and in stock?
The base table is keyed by project, so 'this project's tickets' is a Query on the table.
Choose an access pattern above, or build your own request. See what comes back and what it costs.