In this chapter
We'll see why sharing a name causes real chaos at the register — and give every customer, product, and sale a primary key: a value that's always unique.
The Problem in Real Life
It's a busy Saturday. Sarah is running the register while Mike restocks shelves. A regular customer named Alex wants to add today's purchase to his running tab. Sarah types "Alex" into the system — and two matching names come up.
Both are named Alex. One owes $45. The other owes nothing. The man at the counter insists, a little too quickly, that he's the one who owes nothing.
| Customer | Phone | Balance Due |
|---|---|---|
| Alex | 555-0198 | $0 |
| Alex | 555-0221 | $45 |
Both rows say "Alex." Nothing in this table tells Sarah which row belongs to the person standing at the counter right now.
Which Alex do I even mean?
Sarah
Same Name vs. Unique ID
Can't tell rows apart
Two rows can look identical, with nothing telling you which one is actually which.
The wrong record gets updated
Add a payment to "Alex," and it can land on the wrong Alex entirely.
Relies on facts that can change
A name or phone number can change — and stop reliably identifying the same row afterward.
Duplicates slip in unnoticed
With nothing guaranteed unique, an accidental duplicate customer can be added and nobody would catch it.
What Is a Primary Key, Really?
A name feels like it identifies a person. It doesn't — not reliably, and not for a table. Two unrelated customers can share one. The same customer might get typed in two slightly different ways ("Alex" one week, "Alex R." the next) and now even the same person looks like two different rows. A name was never built to guarantee uniqueness; it's just a label a person happens to go by.
What every table actually needs is something stronger: a value that's guaranteed to be different for every single row, with no exceptions, ever. That's called a primary key.
A primary key is one column (occasionally a small set of columns together) that every row in a table must have, and that no two rows are ever allowed to share. Once a table has one, a single value — like a Customer ID — is enough to point at exactly one row, with zero ambiguity, no matter how many other columns happen to match.
- Unique — no two rows in the table can ever have the same value
- Never empty — every single row is required to have one
- Stable — it shouldn't need to change once assigned, unlike a name, phone number, or address
| Customer ID | Customer | Phone | Balance Due |
|---|---|---|---|
| 101 | Alex | 555-0198 | $0 |
| 102 | Alex | 555-0221 | $45 |
"Alex" can repeat as many times as it wants now — 101 and 102 never will. Sarah just has to ask one more question at the counter to find out which ID belongs to the person in front of her.
| Customer ID | Product | Price | Date |
|---|---|---|---|
| 101 | Apples | $4 | Aug 2 |
| 102 | Bread | $3 | Aug 9 |
The Sales table no longer has to guess what "Alex" means — it just records a Customer ID, and that number is never ambiguous. Pointing at another table's primary key like this has its own name — a foreign key — and it's exactly what the next chapter is about.
Notice what actually made 101 and 102 good primary keys: they mean nothing at all. Nobody will ever want to rename a Customer ID, correct a typo in it, or reuse it for someone else — because it was never trying to describe the customer in the first place, just to label the row. That's not a coincidence. The more "human" and meaningful a value feels — a name, an email, a phone number someone might change next year — the worse a candidate it usually makes for a primary key. A plain, boring, auto-generated number is often the most reliable choice precisely because nobody has a reason to touch it.
This chapter's version — a manufactured ID with no real-world meaning — is common enough to have its own name: a surrogate key. The alternative, using a real-world value that's already unique (an email address, a government ID number), is called a natural key. Occasionally no single column is enough on its own, and a table uses two or more columns together as one combined primary key — a composite key. Different names, same underlying question this chapter just answered: what makes one row impossible to confuse with another?
GreenMart can now point at exactly one customer, one product, or one sale with zero ambiguity — every single time.
Key Takeaway
A primary key doesn't need to mean anything to a human — it only needs to be unique, permanent, and never empty.
Why This Matters
Primary keys are the single idea the rest of this course leans on hardest. The next chapter's foreign keys are only possible because a primary key already exists to point at. Every join, later in Act 3, works by matching one table's primary key against another table's reference to it. Even the constraints chapter right after this one is largely about enforcing the exact two rules — unique, never empty — that a primary key already has to follow.
The Sales table can now point at an exact customer using a Customer ID instead of a name. But that only works as long as the ID it points to still actually exists — what happens when a customer gets deleted, and a tab is still pointing at them? That's exactly where the next chapter starts.