Count the reads behind one screen
Reduce repeated queries while preserving exactly whose data is selected.
When the project growsAbout 2 min read
A correct list can still do repeated work
An endpoint loads a list of applications, then reads related stories for each one. Add criteria and guidance, and several reads may occur per item. The screen can look correct while the statement count keeps growing with the list.
An illustrative pattern of 2 + 4N means two fixed statements and four per item. It is not a measured count for the current app. Also distinguish server-side database operations from requests made by the phone: one browser request can trigger many statements on the server.
Group the reads, preserve the selection
My Next Step uses grouped loaders in application, support and practice work. One approach is to collect parent IDs, fetch related records for that bounded set and assemble the response in memory. Another is to send prepared statements through a database batch API. Fewer transport calls and fewer SQL statements are different improvements.
Keep participant or tenant scoping in every relevant query. Bind values, handle an empty ID set explicitly, and respect the database’s parameter limits by using bounded groups where needed. Preserve ordering, missing-child behaviour and which revision is selected. Faster access is not a reason to widen who can see a record.
SELECT application_id, story_id
FROM selected_stories
WHERE participant_id = ?
AND application_id IN (?, ?, ?);Verify parity before calling it an improvement
Count statements with one item and with a representative larger list. Compare old and new selections, including another participant’s records, empty relationships and duplicates. Inspect response size and execution time too; one enormous query is not automatically better.
The useful result is a measured reduction in avoidable work with the same authorised information. A lower number alone does not tell that whole story.