An organized collection of data, structured so it can be stored, retrieved, updated, and queried efficiently — at a scale no spreadsheet can match, and by more than one person at once.

A spreadsheet caps out around 1,048,576 rows per sheet, and only one person can safely edit it at a time. This course's live dataset alone runs 33,585 rows — production systems run into the billions, queried by many people at once.

Once data must be shared, updated concurrently, kept consistent, or simply outgrows what one file can hold.

Stores data as tables of rows and columns, where separate tables are linked to each other through shared key columns instead of duplicating data.

A fixed schema enforces consistency — every row has the same columns, of the same type. Keys let one table relate to another, which is the model behind transactional systems.

Entities have clear relationships, data must stay consistent (ACID transactions), and the shape of your data is known in advance.

"NoSQL" doesn't mean not SQL — it means Not Only SQL. It supports flexible, often schema‑less shapes: key‑value pairs, documents, and graphs.

When data doesn't fit neat rows and columns, forcing a rigid schema costs more than it helps. NoSQL trades structure for flexibility.

Data is unstructured or evolves often, records vary in shape, or the natural model is a graph rather than a table.

Every query from here on is answered from a job‑seeker's point of view: what are the highest‑paying jobs, and the most valuable skills to learn?

Keywords stick when you use them to answer a real question — not in isolated syntax drills. This is real 2023 job‑posting data, not a toy table.

Any time you're learning a new tool — anchor it to one concrete question and let every keyword answer a piece of it.

A file‑based, zero‑configuration relational database — the entire engine runs inside your browser via sqlitevis. When: learning, prototyping.

An open‑source, production‑grade relational database, installed locally from Chapter 2 on. When: real concurrent traffic, complex queries.

SELECT names the column(s) to return. FROM names the table to read them from — together, the minimum viable query.

SQL has a fixed grammar — SELECT must be written before FROM, or the parser throws a syntax error. (Later: the database doesn't run it in that order — it just has to be written that way.)

Every single query starts here — this pair never disappears, no matter how many clauses stack on top.

List only the columns you need instead of *. Prefix a column with its table — table.column — to remove ambiguity about where it comes from.

* pulls every column, for every row — real I/O cost. Once you JOIN two tables sharing a column name, table.column is the only way to say which one you mean.

Any production query, any wide table, and always once a second table is involved.

select = SELECT. Convention writes keywords UPPERCASE, identifiers lowercase — so a human scanning the query can tell them apart instantly.

Lenient in SQLite; case‑sensitive in PostgreSQL. Lowercasing identifiers avoids the problem entirely.

Copy a mixed‑case SQLite query into PostgreSQL, and it can suddenly fail — the exact reason to standardize now.

LIMIT caps the number of rows a query returns. It is always the final clause.

Every row you don't need still costs I/O and network time. On this live dataset the difference is already 33× — at billions of rows, it's the difference between a query that returns and one that times out.

Exploratory previews, pagination, or sampling before an expensive aggregate on the full table.

DISTINCT collapses the result set to unique combinations of all selected columns — not each column independently.

The engine compares every row to find duplicates — it behaves like an implicit grouping operation. Use it to profile values, not as a default habit.

Answering "what distinct values exist here?" — e.g. before deciding which job titles to filter on.

WHERE filters individual rows against a boolean condition, evaluated row‑by‑row before any grouping or aggregation happens.

Without it, every query scans the entire table. This is the first hint of a distinction that matters later: WHERE filters raw rows; HAVING filters aggregated groups.

Nearly always. Operators: = > < >= <= !=. Text needs quotes; numbers don't.

-- ignores the rest of a line. /* … */ ignores everything between the markers, across multiple lines. Neither executes.

Two real uses: leaving a note for whoever reads this query next — including future‑you — and toggling a line off while debugging, without deleting it.

Whenever a filter or number isn't self‑explanatory, and every time you're mid‑debug and need to disable a clause.

ORDER BY sorts the result set by one or more columns — ascending (ASC, default) or descending (DESC).

NULL ordering is implementation‑defined — and PostgreSQL's default is easy to get burned by: NULLs sort as if larger than any real value, so plain DESC puts every NULL row first, not last.

Any time rank or sequence matters — top‑N lists, chronological views — almost always paired with LIMIT. Add NULLS LAST explicitly whenever NULLs shouldn't win the podium.

Six operators test how a column's value relates to another: = <>/!= > < >= <=.

You've already used = and > in every WHERE so far — this is the full family, not new syntax. <> and != mean exactly the same thing.

Text needs quotes, numbers don't. >=/<= include the boundary value; >/< don't.

<>/!= excludes rows matching a value. NOT reverses whatever condition comes after it — two ways to say the same thing.

Excluding "the bad data" is at least as common as filtering down to "the good data" — knowing one job board is unreliable is a real, common reason to filter.

!= reads like math; NOT reads like English. Both compile to the identical result — pick whichever is clearer for the condition at hand.

AND joins two or more conditions — a row survives only if every condition is true.

Each extra AND can only keep the same rows or remove more — never add rows back. It's a narrowing operator, always.

Whenever a row must satisfy several rules at once — a title and a salary floor, not either alone.

OR joins two or more conditions — a row survives if at least one condition is true.

Same two conditions as AND, opposite effect: OR can only keep the same rows or add more back. It's a widening operator.

Matching any of several acceptable criteria — a role could be either a fit, not both required.

col BETWEEN x AND y is inclusive shorthand for col >= x AND col <= y — one keyword instead of two comparisons joined by AND.

Identical result to the long form, every time — BETWEEN is purely about readability, not new capability. It also works on text and dates, not just numbers.

Any range check with both a floor and a ceiling — a salary band, a date window.

col IN (v1, v2, …) matches any value in the list — shorthand for repeating col = v for each value, joined by OR.

Adding a fourth option means adding one item to the list — not retyping OR job_title_short = '…' a fourth time. Less to get wrong as the list grows.

Matching a text (or numeric) column against a known short list of acceptable values — titles, locations, statuses.

When AND and OR appear in the same WHERE, SQL evaluates AND before OR by default — exactly like multiplication before addition in math. Parentheses override that default and make the grouping explicit.

Relying on the default with 3+ conditions is exactly how wrong rows quietly leak into a result — the query still runs, it just answers a different question than the one you meant to ask.

Any WHERE mixing AND and OR — group each OR'd pair of conditions in its own parentheses, every time, even when the default would happen to agree.

You could work as a Data Analyst or a Business Analyst. Analyst pay differs, so each title gets its own salary floor: Data Analyst over $100,000, Business Analyst over $70,000. You're located in Boston, MA — or open to fully remote ("Anywhere").

1. Location first — job_location IN ('Boston, MA', 'Anywhere'), easiest to eyeball.
2. Each title's own salary rule, OR'd together, in its own parentheses.
3. AND the location requirement onto that whole group.

Any multi-rule real request — build and test one condition at a time, don't write the whole WHERE in one shot and hope.

LIKE matches text against a pattern instead of an exact value. % stands for zero or more of any characters, anywhere it appears in the pattern.

job_title_short is a cleaned‑up category, but the real job_title column is messy free text — "Business Data Analyst," "Data Analyst II (Healthcare Analytics)." = only matches one exact string; LIKE '%…%' matches the fragment anywhere inside it.

Searching a free‑text column for a keyword, when the exact wording varies but a fragment doesn't.

LIKE is case‑sensitive in PostgreSQL. '%analyst%' won't match "Data Analyst" — only lowercase "analyst" verbatim. Use ILIKE for a case‑insensitive match.

_ stands for exactly one character — narrower than %, which stands for any number of characters.

Lets you require a specific single‑character gap — like the space in "business analyst" — instead of "anything, any length" in between two words.

Matching a near‑exact phrase where exactly one character (a space, a hyphen, a digit) is the only thing allowed to vary.

AS renames a column or table in the output only — the underlying data and table name never change.

Real column names like job_title_short are redundant and awkward for a report. Table aliases also mean you type a short prefix instead of the full table name, every time you need one — especially valuable once JOINs bring a second table name into every line.

Presenting results to someone unfamiliar with the raw schema, or shortening a long table name you'll reference repeatedly. AS itself is optional — a space works too, but the keyword is clearer to read.

Find every "data" or "business" analyst‑type role in the messy job_title text — but exclude anything senior — and hand back a clean, aliased two‑column result.

1. "data" or "business" somewhere in the title.
2. …and "analyst" somewhere in it too.
3. …and NOT "senior" anywhere in it.

Any time a request has an "include this, include that, but exclude this other thing" shape — attack one piece of the sentence per line.

A fictitious, single‑table dataset simulating a data freelancer's 2023 invoices — one row per hour‑logging activity on a project.

job_postings_fact doesn't have two numeric columns naturally multiplied together. This one does — hours and a rate — built specifically for arithmetic practice.

Only for this arithmetic‑operators block. Every other section in this course, before and after, uses job_postings_fact.

Arithmetic operators work on numeric columns directly inside SELECT — + and - exactly like a calculator.

Lets you model a "what‑if" change — a rate cut or a raise — without touching the actual stored value. Nothing in the table changes; only the query's output does.

Any what‑if or projection question against a numeric column — accounting asking "what would this look like at a different rate?"

* multiplies. Any arithmetic expression can go anywhere a column can — including inside WHERE.

"Total cost = rate × hours" is the real business question — and once that value is computed, it can itself be the thing you filter on, not just display.

A SELECT alias doesn't exist yet when WHERE runs (execution order, again) — so the full expression has to be repeated in WHERE, the alias can't be reused there.

% returns the remainder left over after dividing — not a percentage.

Answers "how much is left over after full units" — full workdays plus a few extra hours, full boxes plus a handful of leftover items.

Any full‑unit‑plus‑remainder question. Here: how far past a full 8‑hour day did a logged activity run?

Aggregation functions collapse many rows into one summary number. SUM(col) totals a column; COUNT(*) counts rows; COUNT(DISTINCT col) counts unique values.

Arithmetic operators (last section) compute across a single row. Aggregation functions compute down a whole column — a fundamentally different direction, not just a new keyword.

Any total, row count, or "how many unique X exist" question — back on job_postings_fact now.

Same shape as SUM and COUNT — one column in, one number out. AVG the mean, MIN/MAX the extremes.

Center and spread, together — filtering to one title and watching the average move tells you more than either number alone.

Sanity‑checking a subset against the whole — "how far below the overall average does this specific group sit?"

GROUP BY col splits rows into one bucket per distinct value of col — every aggregation function in SELECT then computes separately per bucket, instead of over the whole table.

This is the real explanation for the last slide's drop: the unfiltered average blends all 10 titles into one number. GROUP BY unblends them, all at once, in a single query.

Comparing categories side‑by‑side, instead of running one filtered query per category.

HAVING filters grouped/aggregated results — the same job WHERE does for raw rows, except WHERE cannot reference an aggregate function at all.

Look at the table on the last slide — Cloud Engineer has only 87 postings, far fewer than every other title, and its average is likely skewed by a small sample. HAVING is how you drop it.

The one clear tell: the filter condition itself needs SUM/COUNT/AVG/etc. If it doesn't, use WHERE instead — HAVING runs later, so it's not the default choice.

IS NULL tests whether a column truly has no value stored — not zero, not an empty string, both of which do occupy space. IS NOT NULL is its exact opposite.

This is the real explanation behind the ORDER BY slide from earlier — a missing value has nothing to compare, so it needs a rule of its own for where it sorts. = NULL never works; NULL isn't equal to anything, not even itself.

Validating data quality before trusting an aggregate — flagging incomplete records instead of silently averaging over the gaps.

One row in table A matches at most one row in table B, and vice versa — a strict, single pairing in both directions.

If every row in A always has exactly one partner in B, the two tables usually didn't need to be separate in the first place — 1:1 is the cardinality you almost never deliberately design for.

Security (sensitive columns walled into their own table), or performance (rarely‑read columns kept apart from a huge frequently‑scanned table) — not because the data is naturally two entities.

One row in table A can match many rows in table B — but each row in B points back to only one row in A.

This is the shape under almost every fact/dimension pair in this course — one company_dim row, many job_postings_fact rows. A single foreign key column on the "many" side is all it takes.

B's rows read like "events" or "detail lines," and A's row is the shared "parent" they all reference by ID.

Many rows in A can match many rows in B, and vice versa. Neither side can hold one foreign key pointing at "the" match — there isn't a single one.

A job_id needs to point at several skills at once — impossible for one column. A bridge table (skills_job_dim) fixes this: one row per (job_id, skill_id) pairing, nothing else.

Two ID columns, a name that often literally says "the two things it bridges" — memberships, tags, enrollments, skills.

A LEFT JOIN B ON … keeps every row of A, attaching columns from B wherever a match exists — NULL where it doesn't.

The most common join for an analyst: you already trust A's row count, you're just enriching it with a friendlier label from B.

A RIGHT JOIN B ON … is the mirror — keeps every row of B, attaches matches from A, NULL where none exist.

Same operation as LEFT JOIN, tables swapped — some style guides just standardize on LEFT and reorder FROM instead.

Keeps only rows where the key exists on both sides — anything unmatched on either side is dropped.

The default when the relationship is required, not optional — a job with a company on record, not one that might have one.

Keeps every row from both tables — matched where possible, NULL‑padded on whichever side has no match.

The least common in analyst work — you're auditing mismatches on both sides at once, not answering one specific question.

Chain multiple INNER JOINs, one per relationship, to walk across more than two tables in a single query — the toy 4‑row example, scaled to the real dataset.

Real questions rarely stop at two tables — here, "job → its skills" needs the bridge table and the lookup table in the same query.

Any multi‑table question where a row without a full chain of matches isn't useful data — it's noise.

For every skill: how many postings mention it, and what's the average salary of postings that require it? One query, three tables, two LEFT JOINs, a GROUP BY.

1. Start from skills_dim — every skill should appear even with zero mentions.
2. LEFT JOIN skills_job_dim on skill_id to reach the postings.
3. LEFT JOIN job_postings_fact on job_id to reach the salary.
4. GROUP BY the skill, aggregate, ORDER BY the average descending.

Any "for every X, how many Y and what's the average Z" question — anchor on the dimension you never want to lose, LEFT JOIN outward from there.

This entire course runs against a local PostgreSQL database named sql_course. Creating, altering, or dropping a table needs a real database you control — PostgreSQL + pgAdmin (or DBeaver) + VS Code, all local, no browser tool involved.

If you're following along live, you already have this running. The two downloads on the right are for setting up a second machine, or recovering after a wipe.

Once PostgreSQL is installed and running, everything else — schema, data, indexes — comes from the files on the right.

Every column in a real table declares one fixed data type up front — the same categories job_postings_fact's columns had all along, just invisible to you until now.

A type is a data‑integrity gate — inserting text into an INT column fails outright — and it lets the engine skip guessing, which is part of why a real database out‑performs a spreadsheet at scale.

Once, when you write CREATE TABLE — changeable later with ALTER TABLE, but worth getting right the first time.

CREATE TABLE name (col type, col type, …); declares a brand‑new, empty table with its column names and types fixed up front.

Matches the star‑schema shape you already know — a table is just a name plus a typed column list, nothing more.

Once per new table — the first of four table‑management statements this section covers.

INSERT INTO table (columns) VALUES (…), (…); adds one or more rows — always in the same order the column list specifies.

Listing column names explicitly, rather than relying on the table's stored order, is what keeps this query working if that order ever changes.

Loading data into a table that already exists — multiple rows at once, comma‑separated, in a single statement.

ALTER TABLE modifies an existing table's structure without rebuilding it. ADD COLUMN appends a new one — NULL on every existing row unless a default is given.

Real requirements change after a table already holds rows — you don't want to DROP and recreate it just to add one field.

A new attribute becomes relevant mid‑use — here, tracking who to contact at each company.

UPDATE table SET col = value WHERE condition; changes existing rows in place — WHERE decides which rows, exactly like in a SELECT.

The only one of these four statements that reuses a clause you already know cold — get the WHERE wrong and you don't get an error, you get a wrong (or a wiped) table.

Filling in or correcting data after the fact — here, the contact column ALTER TABLE just added empty.

Renames a column in place — same data, same type, only the label changes. Needs the old name and the new one.

contact turns out to be vague once it specifically holds a person's name — renaming costs one statement, instead of a new column plus a data migration.

A name stops describing what the column actually holds — cheap to fix immediately, expensive to leave wrong.

Changes a column's declared data type after creation — e.g. a capped VARCHAR(50) to unlimited TEXT.

The change only succeeds if every existing value can be reinterpreted as the new type — PostgreSQL checks the whole column, not just future rows.

A length cap turns out wrong, or — rarer, and riskier — the category itself needs to change.

ALTER TABLE table DROP COLUMN name; removes a column and every value it held — permanently, immediately.

The simplest of these statements syntactically, and the most dangerous for exactly that reason — one line, no confirmation, no undo.

A column is confirmed obsolete — here, dropping contact_name once contacts move to being sourced from LinkedIn instead.

DROP TABLE table; deletes the entire table — structure and every row — in one statement.

The most destructive statement in this course. Large tables can take a noticeable amount of time to actually finish dropping in the background, even after the command "completes."

A table's purpose is fully retired — here, retiring job_applied once the plan shifts to tracking applications in a spreadsheet instead.