Building and changing data

Everything so far has been read-only: you asked Daybreak questions and it answered. The commands in this session actually change data - they are how the rows got there in the first place. This is where analysts become builders: you can now stand up a table, seed it, correct it, and evolve it. And here is the safety net that makes learning this painless - every Run in this course starts from a clean, freshly seeded copy of the database. Your writes are real while the query runs, then they vanish. No box affects another box, and no learner affects another learner.

A table is a promise about shape: these columns, these types, these rules. CREATE TABLE writes that promise. Each column gets a type (INTEGER, TEXT, REAL), and you can attach constraints - PRIMARY KEY to guarantee each row is uniquely identifiable, NOT NULL to forbid missing values, FOREIGN KEY to point at another table's key.

CREATE TABLE roasters (
  roaster_id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  country TEXT
);
INSERT INTO roasters VALUES (1,'Highland','Kenya'),(2,'Volcanica','Costa Rica');
SELECT * FROM roasters;

Three verbs change rows. INSERT adds them, UPDATE edits values in rows that already exist, DELETE removes rows. Each box below runs on a fresh seeded copy of Daybreak, so you can hit real customer and order data safely - do the write, then a SELECT right after to see the effect, then run again knowing the next run resets everything.

INSERT INTO customers VALUES (99,'Test Buyer','Oslo','Norway','2026-06-15','Pro');
SELECT * FROM customers WHERE customer_id = 99;

UPDATE products SET price = price + 1 WHERE category='Coffee';
SELECT name, price FROM products WHERE category='Coffee';

DELETE FROM orders WHERE status='cancelled';
SELECT COUNT(*) AS remaining FROM orders;

ALTER TABLE changes a table's structure after it exists - add a column, rename it, drop it. And then the idea that reorganizes how you read every query you have written: SQL does not run top to bottom the way you type it. The engine runs FROM first and SELECT almost last.

CREATE TABLE tmp (id INTEGER);
ALTER TABLE tmp ADD COLUMN label TEXT;
INSERT INTO tmp VALUES (1,'hello');
SELECT * FROM tmp;

Put all four verbs together on a fresh, empty database. Create a small promos table, seed it, correct a value, remove a stale row, then reshape it - the full lifecycle a builder runs every week.

CREATE TABLE promos (code TEXT PRIMARY KEY, pct INTEGER);
INSERT INTO promos VALUES ('SPRING',10),('WELCOME',15);
UPDATE promos SET pct = 20 WHERE code='WELCOME';
ALTER TABLE promos ADD COLUMN active TEXT;
SELECT * FROM promos;

• On a data-seed="none" box, create a suppliers table with an id (PRIMARY KEY), a name (NOT NULL), and a country. Insert three suppliers and read them back.
• On a fresh seeded box, INSERT a new product into products, then UPDATE its price, then DELETE it - proving to yourself the copy resets each run.
• Write an UPDATE that gives every "Pro" customer a note - first add a note column with ALTER, then UPDATE it WHERE plan='Pro'.
• Say out loud, without looking, the seven-step execution order. Then explain why you cannot put a SELECT alias in WHERE.
• Bring one question to b9: if you were handed Daybreak cold, how would you find out why March revenue dropped? Next session answers exactly that.

This session teaches the data-definition and data-modification core of the major free SQL curricula, run on live data instead of screenshots. Graded problem sets stay on the official sites. This page covers: