One table, an application's worth of questions
Generic keys and one overloaded index answer five access patterns with no join and no scan.
Why
This is the whole course in one table. A conference platform has conferences, sessions, speakers and registrations, and five questions to answer. Every item lives in one table, keyed generically, with one overloaded index, GSI1, shared across two entity types.
Run the five examples. A conference and its agenda are one Query; a session and its attendees are another. GSI1 re-keys sessions by speaker and registrations by attendee, so the same index answers both 'every talk this speaker gives' and 'every session this attendee booked'. The fifth is a plain GetItem. Five access patterns, every one a Query or a GetItem, never a join and never a scan.
Model backwards from your access patterns: generic keys and one overloaded index let a single table serve an entire 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.
A conference and its sessions share a partition, so one Query returns the lot, sessions in start-time order.
Registrations live under their session's partition, so a session's attendees are one Query.
GSI1 re-keys sessions by speaker, so every talk Okafor gives, across conferences, is one Query.
The same GSI1, a different entity: registrations re-keyed by attendee. One index, two questions.
The point read that needs no index: one attendee's registration for a session.
Built on this
- Commerce Capstone - How does the whole shop fit together?
A conference and its sessions share a partition, so one Query returns the lot, sessions in start-time order.
Choose an access pattern above, or build your own request. See what comes back and what it costs.