DML: INSERT, UPDATE, DELETE | Relational Databases

In this chapter

We'll put real data into GreenMart's tables for the first time — and meet the three commands (INSERT, UPDATE, DELETE) that add, change, and remove it, closing the loop the very first chapter opened.

12–15 min

The Problem in Real Life

GreenMart's tables exist now, but they're empty. Months of Mike's notebook — every sale, every customer, every tab — still live only on paper. Sarah starts typing it in, one entry at a time, beginning with the exact page that started all of this: Priya's tab, still showing $340 owed.

A minute later, Mike remembers something the notebook never quite solved: Priya paid $200 back last week. This time, Sarah doesn't cross anything out or add a new line — she changes the one row that already exists.

Priya doesn't need a new row. She needs this one updated.

Sarah

Editing a Notebook vs. Changing One Row

Empty tables answer nothing

A perfectly designed table with zero rows still can't tell Mike anything.

Forgetting WHERE is dangerous

An UPDATE or DELETE with no WHERE clause touches every row in the table, not just one.

The notebook's exact problem, revisited

Without UPDATE, "fixing" a number means adding a new row and hoping everyone reads the latest one.

Duplicate rows are just as easy to create

INSERT doesn't stop the same customer from being added twice, unless a constraint from Act 1 catches it first.

What Is DML, Really?

Chapter 1 built the tables. Nothing about that put a single fact inside them. The part of SQL that actually adds, changes, and removes rows — the data itself, never the table's structure — is called DML (Data Manipulation Language).

DML is exactly three commands, and Priya's tab needs all of them before this chapter is over.

INSERT adds a brand-new row to a table.

Putting Priya on the Books

INSERT INTO Customers (CustomerID, Name, Phone, BalanceDue)
VALUES (101, 'Priya', '555-0142', 340);

One row, one customer, one balance — exactly the fact the notebook could never keep straight. INSERT adds it to the table for the first time.

UPDATE changes the values already inside an existing row, without touching any other row.

Priya Pays $200 Back

UPDATE Customers
SET BalanceDue = 140
WHERE CustomerID = 101;

This is the entire idea chapter 1 was building toward: not a new line, not a crossed-out number — the exact same row, changed in place. WHERE matters here more than almost anywhere else in SQL: without it, every customer's balance changes, not just Priya's.

DELETE removes an existing row entirely.

Removing a Row That Shouldn't Exist

DELETE FROM Customers
WHERE CustomerID = 999;

A test row Sarah added earlier while practicing, with no real customer behind it. DELETE removes exactly the row WHERE points at — nothing else.

Look at what WHERE does across both UPDATE and DELETE: it's the difference between changing one specific row and changing every row in the table by accident. Leave it off an UPDATE, and every customer's balance becomes 140. Leave it off a DELETE, and the entire Customers table empties out in one command.

GreenMart's Customers table now has a real row for Priya, and it's finally trustworthy — one balance, always current. That's the notebook's original problem, solved for real.

Key Takeaway

DML changes the data inside a table — INSERT adds a row, UPDATE changes one in place, DELETE removes one. WHERE is what keeps all three pointed at exactly the row you mean.

Why This Matters

This chapter closes the loop the very first chapter opened: a notebook couldn't tell Mike which of three numbers for Priya was true. UPDATE just proved a real database can — the same row, changed in place, with no second page to disagree with it. Every query in the rest of this Act depends on the data actually being correct inside the tables, which is exactly what INSERT, UPDATE, and DELETE are responsible for.

GreenMart's tables finally have real data moving through them. The next chapter is where Mike gets to actually ask them something back.