In this chapter
We'll see why a spreadsheet isn't a database — and meet the three ideas (tables, rows, columns) every database is built from.
The Problem in Real Life
Sarah doesn't jump straight to a real database. Almost nobody does. She reaches for the thing everyone reaches for first: a spreadsheet. A new file, with headers across the top — Customer, Amount, Paid. For about a week, it really does feel like an upgrade.
Then Mike emails the file over to update it, while Sarah is still editing her own copy in another tab. By evening, there are two files. Both claim to be "the real one." Both have different numbers in the same row.
This isn't a fix. It's just the notebook with an autosum button.
Sarah
Spreadsheet vs. Database
No enforced structure
Any cell can hold any text. Nothing stops the same customer from being typed two different ways.
Duplicated, not connected
Add a new order, and you retype the customer's details again. There's no single place that fact lives.
"Shared" file, separate truths
Two people editing their own copy of "the same" file just means two different files, quietly disagreeing.
One broken formula, no warning
Overwrite or delete a formula by accident, and nothing stops you — or even warns you it happened.
What Is a Database, Really?
A spreadsheet feels like a database, because it looks like one — rows, columns, something table-shaped on the screen. But underneath, it's just a grid. Anyone can type anything into any cell. Nothing stops "GreenMart" and "Greenmart" from being treated as two different customers. Nothing stops a formula from quietly pointing at the wrong row after someone adds a new one above it. And nothing stops two people from editing two different copies of "the same" file at the same time.
A real database isn't just a bigger, sturdier spreadsheet. It's a different kind of thing altogether. It's not just a place to put data — it's a system built to enforce rules about that data, so the mistakes above can't happen at all, instead of just being unlikely.
Strip away the specific software, and every database — from the simplest one to the one running behind a bank — is built around the same three ideas:
- A table — one place for one kind of thing (customers, products, sales)
- A row — one specific record inside that table (one customer, one sale)
- A column — one fact that every row in that table must have (a name, a price, a date)
| Customer | Phone | Balance Due |
|---|---|---|
| Priya | 555-0142 | $140 |
| Alex | 555-0198 | $0 |
| Maria | 555-0173 | $75 |
Remember Priya from the last chapter — "340" on one line, "paid 200" on the next? In a real table, she gets exactly one row, with exactly one balance: $140. No second page to disagree with it.
Real software builds on exactly these three ideas — just with different names on the box. MySQL, PostgreSQL, SQLite, and SQL Server are all real databases, running at businesses far bigger than GreenMart. They differ in plenty of details this course will get to later, but every one of them still stores data as tables, rows, and columns. This course uses SQL — the language nearly all of them share — so what you learn here carries straight over to whichever one you use next.
That's the whole idea behind a database. A notebook — or a spreadsheet pretending to be one — mixes everything together in whatever order the day happened, with no rule stopping a mistake. A database is different: every fact lives in one clearly-labeled place, and every row in a table follows the exact same rules as every other row.
GreenMart doesn't need a bigger place to write things down. It needs something structured enough that the notebook's exact problem — three conflicting numbers, no way to know which one is true — simply can't happen again.
Key Takeaway
A database isn't a bigger place to store data — it's a system that enforces structure a notebook or spreadsheet never can.
Why This Matters
Tables, rows, and columns aren't just trivia — they're the shape every idea in this course is built on. The next chapter only makes sense once this model is in place: it asks which tables GreenMart actually needs. Keys, constraints, joins, even the performance chapters much later — they're all really just more detailed answers to one question: "what is a table allowed to do?" And that question doesn't exist until this chapter draws the line between a grid and a real database.
Sarah has decided GreenMart needs real tables, not another spreadsheet. The obvious next question is: tables for what? That's exactly where the next chapter picks up.