Why Advanced SQL Techniques?
The problem with one giant query, and the six tools SQL gives you to break it into clean, reusable pieces.
So far you have written queries that fit on one screen. Real reports are different: "show every team's total runs, rank the teams, keep the top 3, add the team's full name and city, and hide the players' contract details". Written as one giant nested query, this becomes very hard to read, debug and reuse.
This chapter teaches six tools that let you break a complex problem into small named pieces.
The problem with one giant query
| Problem | What it looks like |
|---|---|
| Hard to read | Brackets inside brackets inside brackets — you cannot see where one step ends |
| Hard to debug | When the answer is wrong, you cannot run "just step 2" to check it |
| Repeated logic | The same "total runs per team" calculation is copy-pasted into 5 reports |
| Slow on big tables | The same heavy calculation is re-done every single time someone runs the report |
Definition
Advanced SQL techniques are language features that let you structure, name, store and automate query logic — instead of writing everything as one flat
SELECT.
They fall into three families:
- Structure a single query — subqueries and CTEs split one query into steps.
- Save logic or data in the database — views save a query, CTAS / temp tables save a result.
- Save and automate programs — stored procedures run on demand, triggers run automatically.
The six tools at a glance
| Tool | One-line meaning | Stores data? | Lives for |
|---|---|---|---|
| Subquery | A query inside another query | No | One query |
CTE (WITH) | A named step at the top of one query | No | One query |
| View | A saved SELECT, used like a table | No (only the query text) | Until dropped |
| CTAS / Temp table | Save a query's result as a table | Yes | Until dropped / your session |
| Stored procedure | A saved SQL program with parameters | No (stores code) | Until dropped |
| Trigger | Code that runs by itself when data changes | No (stores code) | Until dropped |
Example — the same question, two styles
Question: which teams scored 700+ runs in total?
sql
-- Style 1: subquery (read from the inside out)
SELECT *
FROM (
SELECT team, SUM(runs) AS total
FROM players
GROUP BY team
) AS t
WHERE total >= 700;
-- Style 2: CTE (read from top to bottom)
WITH team_totals AS (
SELECT team, SUM(runs) AS total
FROM players
GROUP BY team
)
SELECT *
FROM team_totals
WHERE total >= 700;Both return exactly the same result:
| team | total |
|---|---|
| DC | 700 |
| RCB | 750 |
| RR | 850 |
The CTE version reads like a story: "first build team_totals, then filter it". That is the whole spirit of this chapter — clean, reusable, fast SQL.
Note: The course teaches SQL Server (T-SQL). Subqueries, CTEs, views and
CREATE TABLE … AS SELECTall run in the browser playground. Stored procedures, triggers,SELECT … INTOand#temptables are SQL Server features, so those examples are shown as static code you can run in SQL Server Management Studio (SSMS).
Key points to remember
- One giant nested query is hard to read, hard to debug, repeats logic and can be slow.
- Subqueries and CTEs structure ONE query into smaller steps; nothing is stored.
- A view saves the query text in the database; it stores no data of its own.
- CTAS and temporary tables save the query RESULT as real rows in a table.
- Stored procedures are saved programs you run on demand with EXEC; triggers run automatically on INSERT / UPDATE / DELETE.
- Choose the tool by asking: do I need to reuse it, store the data, or automate it?
Try it yourself
Subquery vs CTE — same answer
Runs on a fresh IPL practice database in your browser · edit the query and press Ctrl + Enter
Practice: change the threshold
Runs on a fresh IPL practice database in your browser · edit the query and press Ctrl + Enter
Revision Flashcards
Tap a card to flip it and see the answer.
