How We Verify Our Content

A tutorial that teaches something wrong is worse than no tutorial. Most SQL content on the web is checked by eye, if at all. This site holds itself to a mechanical standard instead: if a claim can be tested by a script, it is, and the tests run before anything goes live. This page explains exactly what “verified” means here, so you can decide how much to trust it.

What the verified badge means

Every tutorial carries a line reading Every example verified. It is not decoration. It means each runnable SQL block on that page was executed against the same sample database you use in the playground, by an automated script, and produced a result without error. Where a block shows the rows it returns, those rows were written out by the script from that run — nobody typed them — and the checks fail if they ever stop matching what the query produces. If a block cannot run on the in-browser engine (for example vendor-specific syntax on the dialect differences page), it is labelled needs a full database instead of being passed off as runnable.

Every example is executed

The tutorials contain more than a hundred SQL examples. Before a page is published or changed, a script extracts every code block marked as runnable and sends each one through the same worker the playground uses — the same sample data, the same statement splitting, the same engine — starting from a fresh database for every block, exactly as a Run click does. Any error stops the change from going out. The Run button comes from that mark rather than from the script: a block gets one only when it is marked runnable, and every block marked runnable is one the script has executed. 196 blocks also publish the rows they return — across the tutorials and the glossary, whose examples go through the same script; those tables are generated by a script, never typed, and compared against a fresh run every time the checks run.

Every exercise solution is checked end to end

All 42 practice exercises ship with a reference solution. Two checks apply to each one:

1. The reference solution is executed against a freshly built database and must return rows.
2. A browser-automation suite opens the real practice page, types the reference solution into the editor, presses Check answer and confirms the checker accepts it — the exact path a visitor takes.

Answer checking itself never compares your SQL as text. It runs your query and the reference query against the same data and compares the two result sets, so any query producing the correct rows is accepted. When you are wrong, it shows the expected rows next to yours so the difference is visible rather than described.

Comparing results has two consequences worth naming. Where a task asks for a column by name — a column named headcount — the name is part of the answer, so 13 tasks check it and tell you which name they expected; everywhere else you are free to alias however you like. And because the checker only ever sees the rows your query returns, it would otherwise accept those rows typed out as literals. So it runs both queries a second time against an empty copy of the database: a query that reads the tables answers differently, a query that invented its values answers exactly the same, and the second kind is refused. Both behaviours are tested by a published script.

We test that a wrong answer is actually rejected

Checking by result has one weakness, and we would rather name it than hide it: on a small sample database a wrong query can return the right rows by coincidence. So a script takes all 42 reference solutions, mechanically breaks each one — removes the WHERE clause, flips the sort, widens a comparison, turns a LEFT JOIN into an INNER JOIN, drops DISTINCT or HAVING — and reports any broken version the checker still accepts.

Running it changed the sample data. Every department used to have employees, which meant the exercise about “departments with nobody” could not tell LEFT JOIN from INNER JOIN. All eight customers were in eight different countries, so DISTINCT did nothing. No product sat on a price boundary, so more than 400 and 400 or more were the same query. Those are fixed: one department is empty, two customers share a country, one product costs exactly 400, and one order total sits exactly on the CTE exercise’s threshold.

Five exercises are still not fully discriminating, and the honest reason is that they cannot be on data this size. Four are ordering questions where the grouped result happens to come back already sorted, so a missing ORDER BY is invisible in the output. One compares against the company-wide average salary, where placing an employee exactly on the average would move the average. The script records that number as a baseline and fails if it ever grows, so the checking can only get stronger.

Structured data must match the page

Search engines are told about this site through schema.org markup: article headlines, FAQ questions and answers, how-to steps, glossary definitions. A script compares every one of those strings, character by character, with the text actually rendered on the page. If a FAQ answer in the markup does not appear on the page, the check fails. Dates in the markup are generated from the same source as the visible Updated line. Nothing is told to a search engine that is not shown to you.

Accessibility and layout are tested, not assumed

Every page is checked with axe-core against WCAG 2.1 AA in both light and dark mode, and must report zero violations. Every page is also rendered at phone, tablet and desktop widths and must not overflow horizontally, and layout shift is measured so that content does not jump as it loads. These checks are run before a change goes out.

Counts are checked against the code

When a page says “42 exercises” or “four paths”, a script confirms that number against the exercise bank itself. If the bank grows and a page still quotes the old figure, the check fails until the text is corrected.

What we will never do

• No invented social proof. There are no testimonials, star ratings, “trusted by” logos or user counts on this site, because we could not verify them. Every number shown is a count of something that exists in the code.
• No copied content. Every tutorial, exercise, prompt and explanation is written for this site against its own fictional sample database.
• No tracking. No analytics, no cookies, no third-party scripts. The privacy policy describes the little the site remembers, and that description is checked against the code too.
• No pretending an example works when it does not. Dialect differences are stated; unsupported syntax is labelled.

You can run these checks yourself

Claiming that a script checks something is worth very little if nobody can see the script. Every check described on this page is published in the site’s repository under scripts/verify/, with an npm command each:

• npm run verify:sql — executes every runnable example in the tutorials
• npm run verify:exercises — solves all 42 exercises through the real page
• npm run test:exercises — checks that a wrong answer is actually rejected
• npm run verify:grader — required column names are enforced, invented answers are refused
• npm run verify:claims — legal pages, no fabricated proof, schema against the rendered text
• npm run verify:pages — head tags, internal links, sitemap, published counts
• npm run verify:a11y — axe-core WCAG 2.1 AA in both themes, overflow, console errors, layout shift

If one of them disagrees with something written here, the page is wrong and we would like to know.

Corrections

None of this makes the site infallible — it makes it correctable. If you find a mistake, a misleading explanation or an example that behaves differently on your database, tell us. Corrections are made in the page itself, the Updated date changes, and the checks above run again before the fix goes live.

Who writes this

SQL Practice is an independent project, built and maintained in India for learners everywhere. Content is written and reviewed by the site’s maintainer with the verification tooling described above; there is no editorial board, no sponsor and no advertiser influence over what is taught. Read more on the About page.

Related reading

• About SQL Practice
• Privacy Policy
• Contact