Traverse a relationship both ways
An index that swaps the partition and sort keys reads the same edges from the other side.
Why
A maintainer belongs to many projects, and a project has many maintainers. Each membership is stored once, as an edge item keyed pk = PERSON, sk = PROJECT, carrying a second pair of keys that swap the two: gsi1pk = PROJECT, gsi1sk = PERSON.
So the base table answers 'Ada's projects' and the inverted index answers 'httpkit's maintainers', from the very same edges. One relationship, two directions, nothing duplicated. The profile items carry no index keys, so only the edges appear in the index.
Store a many-to-many as edges, then an inverted index, partition and sort swapped, reads the relationship from either side.
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 the base table, Ada's partition holds one edge per project she maintains.
The same edges, read through the inverted index keyed the other way round: who maintains httpkit.
No sort-key condition: Ada's whole collection, her profile and every edge, in one Query.
Built on this
- Maintainers & Projects - Who maintains this project?
On the base table, Ada's partition holds one edge per project she maintains.
Choose an access pattern above, or build your own request. See what comes back and what it costs.