Teaching SQL: real queries from the first hour

The real obstacle is not the language, it is the database

SQL is one of the most approachable languages you can teach: its syntax reads almost like a sentence, and a beginner produces a useful query within minutes. The obstacle lies elsewhere.

Before writing a single SELECT, you need a database at hand. And that is where SQL courses lose their first half day:

• Installing a server on every machine requires administrator rights that learners almost never have.
• Sharing one database raises the opposite problem: the first clumsy DELETE ruins the dataset for the whole group.
• Providing remote access means a server to administer, accounts to create, and a firewall to convince.

The simplest answer is to give everyone their own database, in their browser, already populated. Nobody installs anything, nobody breaks anyone else's work, and an unfortunate DROP TABLE costs one page reload.

A dataset that needs no explaining

The choice of dataset weighs on a course's success more than people imagine. Too rich a database forces you to explain the business before the language; too poor a one allows no interesting join.

The model that works everywhere fits in four tables: customers, products, orders, and the lines of those orders. Everyone grasps the meaning without preamble, and that structure is enough to cover the essentials:

• Filtering and sorting on the customers table.
• Aggregates — counting, summing, averaging — on products.
• The simple join between orders and customers.
• The multiple join and grouping, to compute revenue per customer.

Keep the volume modest: about ten rows per table. A result you can read in full on screen lets learners check for themselves that the query did what they thought.

The order that avoids dead ends

The classic textbook progression follows the order of the syntax. The order that works in a classroom follows actual difficulty instead — and that is not where you would expect.

Start with reading, not writing. A ready-made query, run and observed, installs the key idea: a query returns a table. Then have them modify it — change a city, add a sort — before asking for one from scratch.

Introduce joins early. It is counter-intuitive, but the join is the heart of SQL and the source of most dead ends. Pushing it to the end of the course suggests the rest is settled, while half the group stalls on the first one.

Save GROUP BY for last. Grouping demands thinking in sets rather than rows: a genuine conceptual leap that deserves time and visual examples.

The three mistakes that always come back

Three misunderstandings turn up in every group, at any level. Anticipating them saves an hour.

• The forgotten join. Two tables in the FROM, no linking condition, and the query returns the product of every row. The result is enormous and nobody understands why. Show it deliberately once: it is the most effective demonstration there is.
• The filter in the wrong place. Filtering before or after a grouping does not give the same result. Have both versions written side by side rather than explaining the rule.
• Comparing against a missing value. An empty field does not compare like the others: the query returns nothing, without error, and the learner hunts elsewhere for ten minutes.

These three share one trait: the query does not crash. It silently returns a wrong result. Hence the importance of a dataset small enough to check by eye.

Correcting live, without giving the answer too early

SQL lends itself particularly well to collective correction: a query fits in a few lines, and the result is immediately visible to everyone.

The most effective setup is to project your own screen while everyone works in theirs. You write a query, it appears on their side; they adapt it without retyping from memory. When correcting, show the expected result first — the table, not the query. The group then looks for the path, which is exactly the exercise.

Keep the solution written in advance but hidden, and reveal it only afterwards. A solution visible too early turns a reasoning exercise into a copying exercise.

What still needs a real server

A database in the browser covers everything you query. It does not cover what you administer, and that distinction is better stated plainly to the group.

Still to be handled in a real environment: rights and users, backups, optimisation and indexes at serious volumes, concurrent transactions, and dialect differences between engines. These topics belong to the administrator's craft more than to writing queries.

For an introduction, a refresher, or a SQL module inside a broader course, the browser is more than enough — and it frees the half day that went into installing.