Keys — Giving Everything a Name

Lesson 4 · taught by Pip

Last lesson we said each fact should have one home. But to point at that home, you need its address — a way to name one exact row and no other. That's a key: a unique label for one row, like a name no two things share. It lets a database point at exactly one customer, one order, one anything — with zero confusion, even when two of them look identical.

Think of how a school gives every student an ID number. Two kids can both be named Sam Lee, but only one carries ID 4471. When the office needs that Sam, they don't squint at names and guess — they use the number. A key is that ID number, for rows.

Why a name isn't enough

You might think a customer's name could be their key. It can't, and here's the snag: names repeat. Two different people are both "John Smith." Two products are both called "Classic Mug." If you ask the database for John Smith, it shrugs — which one? Any fact you'd naturally use can collide like this. Even emails change; even phone numbers get reassigned.

So a database gives each row its own dedicated tag, a column whose entire job is to be unique. Often it's just a plain number, counting up — customer 1, customer 2, customer 3. It's not pretty and it's not meant to be read aloud. It exists so the system can grab one exact row and never the wrong one. This tag is called the primary key: the one, true name of that row.

A key never lies twice

The promise of a primary key is simple but strict: no two rows in a table may share one. The moment you try to add a second customer 1, the database refuses. That refusal is a feature, not a nuisance — it's the system guarding against duplicates on your behalf, so "customer 1" always means one specific person and always will.

Because the key is steady, you can hand it around safely. Other tables, other systems, other reports can all say "customer 1" and know they mean the same person, today and next year. The name on the account might change; the key underneath stays put, a quiet anchor.

You meet keys all day

Keys aren't a database oddity — they're everywhere once you look. Your bank account number is a key. An order confirmation number is a key. A library book's barcode is a key. Each one exists for the exact same reason: a name or a title isn't unique enough, so something gives every item its own unmistakable tag. When a support agent asks for your order number instead of your name, they're reaching for the key, because it points at one order and no other.

Why this matters

Keys are the hinge the rest of databases swing on. Without a reliable way to name one row, you can't link tables, can't update the right record, can't trust that a report counted each thing once. The humble key — often just a number you never see — is doing quiet, essential work under everything.

It's also the cure from the last lesson, finished. Each fact gets one home, and the key is the address of that home. That's how an order can point at a customer without copying the customer's details: it just stores the customer's key.

Your turn

Find three keys in your own life right now — a customer number, an account ID, a confirmation code. For each, notice the question it answers: "which exact one?" That's the whole job of a key. Hold that, because next we use keys to tie two tables together.

Next we'll connect tables using these keys, and watch separate grids start working as one. 🔦