SQL
A SELECT query is the read side of your feature. It should return the exact rows and columns your screen, API route, or CLI command needs.
Before writing SQL, write the question your feature must answer. For a campus event app, it might be: “Show upcoming events for this college, newest first.”
That question tells you the table, columns, filters, and order. Do not start with SELECT * unless you are quickly exploring data.
0 of 8 lessons done · proved by a submitted project with a public repository
This query reads only what an event list card needs. It skips internal columns like created_at if the screen does not show them.
-- queries/list_upcoming_events.sql
SELECT
id,
title,
venue,
starts_at
FROM events
WHERE college_id = 1
AND starts_at >= '2026-01-01 00:00:00'
ORDER BY starts_at ASC
LIMIT 10;Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Put read queries in a queries folder. Give each file a task name, not a vague name like test.sql.
Good names help recruiters understand your feature fast: list_upcoming_events.sql, find_student_by_roll.sql, search_hostels.sql.
SELECT * is okay for checking a table in your SQL client. It is not good for feature code or repo demos.
It can expose fields you did not mean to show, like phone numbers. It can also make later schema changes break your app in confusing ways.
A search query usually has a text filter, a stable sort, and a limit. Later in this track you will make inputs safe with parameters. For today, focus on the shape of the read.
-- queries/search_events_by_title.sql
SELECT
id,
title,
venue,
starts_at
FROM events
WHERE college_id = 1
AND title LIKE '%hack%'
ORDER BY starts_at ASC, id ASC
LIMIT 20;Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Answer the quick check to finish this lesson.