Rules at the Door

Last lesson you picked up the pen — and met the damage a pen can do. The library's first line of defense isn't carefulness, though. Careful humans have bad Tuesdays. The first line of defense is a librarian who refuses bad cards at the desk, before they ever reach a drawer.

Constraints

A constraint is a rule attached to a table when it's designed — a standard the database itself enforces on every write, forever, no matter who's writing or how tired they are. You've met one already without the name: a column's type is a constraint ("numbers only in this blank"). Real tables go further and pin down what a card must look like to be acceptable, not merely well-typed.

The two workhorses:

NOT NULL — this blank may not be empty. In databases, an empty blank has a name, NULL — "no value here," not zero, not an empty piece of text, but nothing at all. Some blanks are fine empty (not every member has a phone). Some are nonsense empty: a member card with no name, a loan with no due date. Mark those columns NOT NULL, and the librarian hands incomplete cards straight back:

INSERT INTO members (joined) VALUES ('2026-08-24');
-- refused: members.name may not be NULL

UNIQUE — no two cards may share this value. Emails are the classic: two members with one email address means password resets and messages land with the wrong person. Declare the column UNIQUE and the second registration is refused on the spot — not flagged for cleanup later; refused, now. (Sound familiar? A primary key is exactly this pact at full strength: UNIQUE and NOT NULL, the rule every other rule leans on.)

Why the door beats the mop

There are two moments to catch a bad fact: at the door, or after it's been living on the shelves. The economics aren't close. At the door, the cost is one error message to whoever's writing, while the mistake is still in their hands and their head. On the shelves, the bad card has had time to breed — reports summed it, screens displayed it, other records pointed at it — and someone must now find every consequence and mop. In Unit 1 you watched duplicated facts drift into contradiction; constraints are the same philosophy pointed at quality: make the wrong thing impossible instead of promising to fix it.

Which reframes something from last lesson. That refusal when you tried to file "banana" as a number felt like the database being fussy. It was the database being loyal — every rejection at the door is a mess you never meet on the shelves.

The beginner's stumble here is the opposite one: constraining nothing, because rules feel like friction while you're building. Then the app above the database grows a thousand users, and the drawers quietly fill with nameless members and shared emails — every one a tiny landmine for some future query. Declare the obvious rules on day one; they're cheapest before the first card is filed.

Constraints guard each card, one at a time. But some mistakes live between writes — two changes that only make sense together, and a power cut lands in the gap. For that, the vault has its deepest promise: all or nothing. Next lesson.