SQL describes the rows you want from a relation. A table has named columns and rows; a query produces another relation. Start by asking what one output row represents, then list the columns you need. In this lesson one row is one qualifying run, not one model. Two different runs can have the same model name and score and still represent different observations.
This track uses SQLite. You write SQL directly in .sql files; neither C++ nor Python knowledge is required. SQL keywords are conventionally uppercase, string literals use single quotes, and statements end with semicolons. A -- comment extends to the end of a line. The SQLite shell's .mode and .schema commands are shell commands rather than SQL, so use SELECT and CREATE TABLE in the editors here.
Follow the data
A useful logical model is FROM → WHERE → SELECT → ORDER BY → LIMIT. SQLite may choose a different physical execution plan, but it must produce the requested result. WHERE keeps rows for which its predicate is true. Combine requirements with AND when both must hold; use OR for alternatives and parentheses when mixing them.
SELECT names the output columns. Prefer explicit names over SELECT * in a stable report: adding a source column should not silently change the result contract. AS gives an expression an output name. The grader checks output column names and duplicate counts as well as values.
Tables have no promised presentation order. Add ORDER BY whenever the contract asks for ordered rows. If you limit to three rows and several scores tie, ordering by score alone leaves the cutoff ambiguous. Add a unique id as the final tie-breaker. Filtering before limiting matters: the top three source rows might all be inactive.
Work a complete example
The example includes its own schema and data. Every Run creates a new SQLite database, so changing or rerunning it cannot change your other exercises.
CREATE TABLE runs(id INTEGER PRIMARY KEY, model TEXT NOT NULL, score INTEGER NOT NULL, active INTEGER NOT NULL CHECK(active IN (0,1)));
INSERT INTO runs VALUES (9,'d',90,1),(1,'a',90,1),(2,'b',80,1),(3,'c',100,0),(4,'e',79,1);
SELECT id, model, score
FROM runs
WHERE active = 1 AND score >= 80
ORDER BY score DESC, id ASC
LIMIT 3;Diagnose the common failure
A predicate can be valid SQL and still implement the wrong requirement. active = 1 OR score >= 80 admits inactive high scores and active low scores. A query with no ORDER BY can appear stable on a small sample while returning a different order after an index is added. Those are logic errors, which is why bug hunts grade behavior against multiple fixtures.
Try a change before building
Change the threshold to 90, keep at most two rows, and retain increasing ids among equal scores. Predict the result before clicking Run. Then remove the tie-breaker and explain which part of the result contract you no longer specify.
Move into practice
Read tables, project columns, combine predicates and make top-k results deterministic. Checks test the rules; bug hunts ask you to identify a faulty line before seeing its test evidence. The fill-in keeps most of a working statement, and the build asks for the full contract. Public and hidden fixtures vary inputs, preserve duplicate counts and distinguish NULL from text. SQL results appear as tables; predict-output checks use compact JSON rows, one row per line, with null for SQL NULL.
Use the Watch & read resources for the lecture and primary SQLite reference. Reading or watching alone does not grant mastery. These are SQLite exercises; PostgreSQL, MySQL and SQL Server differ in types, syntax, query plans and concurrency behavior.