Why SQL Still Matters in the AI Era

SQL (Structured Query Language) is the standard language for asking questions of relational databases — the systems that store most business data, from orders and customers to transactions and events. This lesson explains what SQL does, why it remains the most-requested data skill in analyst job postings even though AI tools can now write queries from plain English, and introduces the e-commerce dataset used throughout this course.

The skill has moved, not disappeared

AI assistants translate English into SQL fluently. Ask one for "revenue by month" and you'll get a syntactically valid query in seconds. So why learn SQL at all?

Because a query that runs is not the same as a query that's right. SQL's most dangerous property is that wrong queries rarely crash — they return numbers. Plausible numbers. A query that silently double-counts revenue through a join looks identical, on screen, to one that doesn't. The person who catches the difference is the person who understands what the query actually does.

Here's a preview of the problem this course keeps returning to. Both of these queries run without error, and both claim to answer "what is our total revenue?":

-- Query A
SELECT SUM(total_amount) AS revenue
FROM orders
WHERE status = 'completed';

-- Query B
SELECT SUM(o.total_amount) AS revenue
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
WHERE o.status = 'completed';

-- Query A result:  revenue = 1,204,350
-- Query B result:  revenue = 3,687,410

Query B counts each order once per item in it — a three-item order contributes its full total three times. An AI assistant produced Query B from a perfectly reasonable prompt, and nothing about the output looks broken. By Lesson 4 you'll spot this failure instantly; by Lesson 8 you'll have a repeatable protocol for auditing any query, whoever — or whatever — wrote it.

So the working skill in 2026 isn't typing SQL from memory. It's three things: knowing what question to ask, reading a query well enough to verify it answers that question, and knowing the failure modes that make results silently wrong. Syntax is the entry fee for those three.

What a relational database is

A relational database organises data into tables — rows and columns, like a strict spreadsheet. Each table holds one kind of thing, and tables reference each other through shared ID columns called keys.

This course uses a realistic e-commerce dataset with five tables:

Table	One row per	Key columns
customers	customer	customer_id, name, email, country, created_at
products	product	product_id, name, category, price
orders	order	order_id, customer_id, order_date, total_amount, status
order_items	line item within an order	order_item_id, order_id, product_id, quantity, unit_price
refunds	refund	refund_id, order_id, amount, refund_date

The relationships matter more than the columns: one customer places many orders; one order contains many order items; one order may have zero or more refunds. Almost every silent error you'll meet in this course comes from mishandling one of these one-to-many relationships.

Your first query

A SQL query describes the result you want; the database works out how to produce it. The simplest form:

SELECT name, country
FROM customers
LIMIT 3;

name            country
--------------  --------
Amara Okafor    NG
Li Wei          SG
Sofia Martins   PT

Read it as a sentence: select these columns, from this table, and limit the output to three rows. That declarative style — say what, not how — is why SQL has outlived five decades of tools built to replace it.

All examples in this course use standard SQL and run unmodified on SQLite, DuckDB, and PostgreSQL. Where dialects differ (mostly around dates, in Lesson 7), the lesson says so.

Who this course is for

You need no Python and no prior database experience. If you've used spreadsheet filters and formulas, you already have the right instincts — SQL makes the same operations explicit, repeatable, and auditable. The course is also deliberately useful if AI writes most of your SQL already: every lesson pairs "here is what correct looks like" with "here is the mistake generated queries actually make."

What comes next

The next lesson covers the core of every query — SELECT, WHERE, and ORDER BY — and the first family of silent errors: filters that quietly drop the rows you meant to keep.

Summary

• SQL is the standard language for querying relational databases, and remains the most in-demand data-analysis skill even though AI tools can generate queries from plain English
• Wrong SQL rarely errors — it returns plausible numbers, so the durable skill is reading and verifying queries, not typing them
• Relational databases store data in tables linked by key columns; one-to-many relationships (customer→orders, order→items) are the source of most silent query errors
• This course uses one consistent e-commerce dataset (customers, products, orders, order_items, refunds) so you can build intuition for how real schemas behave

---

Lab

No code to write yet — this lab checks that you can navigate the schema, which is the skill every later lesson builds on.

Question 1: Which table answers which question?

For each business question, name the table (or tables) you'd need:

a. "How many customers signed up in March?"

b. "What is the average number of items per order?"

c. "Which product category is refunded most often?"

Answer — Question 1

a. customers alone — created_at gives the signup date.

b. order_items alone can count items per order (group by order_id), though you'd join orders if you want to include orders with zero items or filter by order status.

c. Three tables: refunds links to orders by order_id — but refunds are recorded per order, and categories belong to products. You need refunds → orders → order_items → products to reach category, and you'd have to decide how to attribute an order-level refund across its items. Real schemas make some questions genuinely awkward — noticing that before querying is the judgment this course trains.

Question 2: Spot the relationship

A colleague says: "I'll join customers to order_items directly to get each customer's purchased products." What's wrong with that plan?

Answer — Question 2

There's no shared key between customers and order_items. Customers link to orders (customer_id), and orders link to items (order_id). The path is customers → orders → order_items. Joins can only follow keys that actually exist — a query that guesses at a relationship will either fail or, worse, join on the wrong column and return garbage that looks like data.

Question 3: The two-query problem

Look again at Query A and Query B from the lesson. Without knowing any SQL beyond what this lesson covered, which single fact about the tables explains why Query B's number is roughly three times larger?

Answer — Question 3

order_items has one row per line item, and orders average about three items. Joining orders to order_items repeats each order row once per item, so SUM(o.total_amount) adds each order's total about three times. The join didn't create wrong data — it changed what one row means, and the SUM kept operating as if nothing had changed. That "unit of one row" question is the through-line of this entire course.