One index, many questions
Different entity types share generic index keys, so one index serves several access patterns.
Why
Here one table holds projects and tasks, and one index, GSI1, serves both. The trick is generic key names: projects write OWNER#ada into gsi1pk, tasks write STATUS#doing into the same attribute.
So one index answers 'Ada's projects' and 'tasks in progress': two access patterns, two entity types, one set of index keys. This overloading is the heart of single-table design.
Generic, overloaded keys let one index do the work of many. That is how a single table serves a whole application.
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.
On GSI1, project items set gsi1pk to OWNER#ada. So this Query returns Ada's projects.
On the same GSI1, task items set gsi1pk to STATUS#doing instead. The very same index now answers a different question.
Built on this
- Contacts CRM - How do I find this contact?
- Commerce Capstone - How does the whole shop fit together?
On GSI1, project items set gsi1pk to OWNER#ada. So this Query returns Ada's projects.
Choose an access pattern above, or build your own request. See what comes back and what it costs.