Does my child need to install a database before starting?

No. Sessions are spoken and work from small tables Evelyn describes or the student reads from their own coursework. If you want hands-on practice between sessions, a free browser SQL sandbox is enough — nothing needs installing.

How is this different from what they already do in Excel or Google Sheets?

Spreadsheets store everything in one flat grid, which means repeated data and no enforced structure. This topic covers why data is split across linked tables, how keys stop duplicate and contradictory records, and how SQL asks a question of that structure. Students who know spreadsheet formulas usually pick up SELECT and aggregate functions quickly.

Which version of SQL is taught?

Standard SQL syntax that works across SQLite, MySQL and most school platforms — SELECT, WHERE, ORDER BY, GROUP BY, INNER JOIN. If your course uses a specific dialect or a tool like Access, tell Evelyn at the start of a session and examples can be adjusted.

Is this useful if they are only doing Year 9 or Year 10 computing?

Yes. Database structure, primary keys and simple SQL queries appear in most 14–16 computing courses, and the same ideas feed into later work on data handling and back-end programming. Sessions can also work directly from a class assignment or database design task.

Data & Databases

High School (9-10) · Computer Science

This topic covers how structured data is stored, related and queried, using relational databases and SQL. Sessions work from real table structures — students, orders, library loans, match results — and build up from single-table queries to joins across two or three tables. Students learn why data is split across tables rather than kept in one giant sheet, how keys link records, and how to write queries that answer a specific question rather than dumping every row. Work is done by talking through query logic out loud and reading results back, so students explain what a query returns before and after running it.

Start a session on Data & Databases

What this covers

Designing a table: choosing fields, picking data types (TEXT, INTEGER, DATE, BOOLEAN) and deciding what belongs in a record
Primary keys and foreign keys — creating a link between two tables and tracing a record from one to the other
Writing SELECT queries with WHERE, AND/OR, LIKE, ORDER BY and LIMIT to filter and sort real data
Aggregates and grouping: COUNT, SUM, AVG, MIN/MAX with GROUP BY to summarise by category
INNER JOIN across two tables, and reading an entity-relationship diagram to work out which fields to join on
Recognising and fixing flat-file problems — repeated data, inconsistent entries, missing values — and splitting one table into two

Where learners get stuck

Treating NULL as if it were zero or an empty string: In a spreadsheet a blank cell behaves like nothing and often counts as 0 in a sum. In SQL, NULL means 'unknown', so `WHERE grade = NULL` returns nothing, AVG silently skips NULLs, and COUNT(column) and COUNT(*) give different answers. Students only notice when a total looks wrong.
Confusing WHERE and HAVING when grouping: Both read as 'only show me the ones where...' in English. Students don't yet picture the order the database works in — filter rows, then group, then filter groups — so they try to put COUNT(*) > 3 in the WHERE clause and get an error they can't interpret.
Expecting a JOIN to just glue two tables side by side: Students imagine copy-pasting one table next to another, so a join that returns more rows than either original table looks like a bug. It comes from not seeing that each row is matched against every row it links to, and from forgetting the ON condition, which produces every possible combination.
Assuming a primary key must be a meaningful piece of information: Early examples use things like email or surname as the key, so students conclude the key should describe the record. They then hit trouble when two people share a name, or when someone changes email, and don't yet see why an arbitrary ID column is used instead.

What a session looks like

A typical session runs 30–45 minutes of spoken back-and-forth. Evelyn starts with a small dataset — say a table of books and a table of loans — and asks the student to describe what each column holds and which field could link them. From there the student is given a question in plain English ('which member has the most overdue books?') and dictates the query clause by clause, saying what WHERE does before saying what GROUP BY does. Evelyn pushes for a prediction of the result set size before the query is described as running, then works through any mismatch. Sessions usually end with the student restating one rule in their own words, such as when a foreign key is needed or why a join lost rows.

Helpful to know first

Comfortable reading a table of data — rows, columns, headers — such as in a spreadsheet
Basic arithmetic including averages and percentages, for interpreting aggregate results
Able to break a question into conditions ('published after 2010 AND borrowed more than twice')
No prior programming needed; Python experience helps with logic but is not assumed

Questions

Does my child need to install a database before starting?: No. Sessions are spoken and work from small tables Evelyn describes or the student reads from their own coursework. If you want hands-on practice between sessions, a free browser SQL sandbox is enough — nothing needs installing.
How is this different from what they already do in Excel or Google Sheets?: Spreadsheets store everything in one flat grid, which means repeated data and no enforced structure. This topic covers why data is split across linked tables, how keys stop duplicate and contradictory records, and how SQL asks a question of that structure. Students who know spreadsheet formulas usually pick up SELECT and aggregate functions quickly.
Which version of SQL is taught?: Standard SQL syntax that works across SQLite, MySQL and most school platforms — SELECT, WHERE, ORDER BY, GROUP BY, INNER JOIN. If your course uses a specific dialect or a tool like Access, tell Evelyn at the start of a session and examples can be adjusted.
Is this useful if they are only doing Year 9 or Year 10 computing?: Yes. Database structure, primary keys and simple SQL queries appear in most 14–16 computing courses, and the same ideas feed into later work on data handling and back-end programming. Sessions can also work directly from a class assignment or database design task.