Lesson 1 of 4
What Is a Database?
"You can have data without information, but you cannot have information without data." — Daniel Keys Moran
Every application you have ever built or used is, underneath the buttons and screens, a machine for turning data into decisions. The posts in a feed, the items in a cart, the messages in a thread, your bank balance — all of it lives somewhere, waiting to be found, changed, and trusted. That somewhere is a database, and learning to wield one well is the difference between an app that works on your laptop and a system that serves millions without losing a single row.
You have spent six volumes learning to compute. This volume is about learning to remember — reliably, at scale, under pressure, and years after the code that wrote the data was itself rewritten. It is one of the most durable skills in software: languages and frameworks churn, but SQL and the relational model have quietly run the world since the 1970s and show no sign of leaving.
Why did the industry standardize on databases — a separate, specialized system — instead of just keeping data in files or in memory like any other part of a program?
What a database actually is
A database is an organized collection of data, and a database management system (DBMS) is the software that stores it, protects it, and answers questions about it. When people say "the database," they usually mean both: the data and the engine that guards it.
You could, in principle, store your app's data in plain files — a customers.csv here, an orders.json there. People did, and some still do. But the moment your data matters, you run into a wall of hard problems that a DBMS exists to solve for you:
| The problem | What happens without a DBMS | What a DBMS gives you |
|---|---|---|
| Finding data fast | Scan the whole file every time | Indexes that find a row in milliseconds among billions |
| Many writers at once | Two writes clobber each other | Concurrency control and transactions |
| Crashes mid-write | A half-written file corrupts everything | Durability — committed data survives a power cut |
| Relationships | You hand-join files in code, badly | Joins across tables, expressed declaratively |
| Rules & integrity | Any bug can write garbage | Constraints that reject invalid data at the door |
| Asking new questions | Write a new program each time | One language — SQL — for any query |
That last row is the quiet revolution. With a DBMS you don't write code to fetch data; you describe the result you want and let the engine figure out how to get it. That declarative style is why a single query language has outlived generations of programming fashions.
Where this came from In 1970, an IBM researcher named Edgar F. Codd published "A Relational Model of Data for Large Shared Data Banks." His radical idea: stop making programmers navigate data by hand through pointers and hierarchies, and instead model everything as simple relations — tables of rows and columns — queried with a formal, math-backed language. IBM's prototype became SQL; Oracle shipped the first commercial version in 1979. Fifty-plus years later, Codd's tables still underpin banking, e-commerce, healthcare, and probably the app on your phone right now.
The relational model in one picture
A relational database organizes data into tables (formally, relations). Each table has:
- Columns (fields/attributes) — each with a name and a type, e.g.
ageholds integers. - Rows (records/tuples) — one entity each, e.g. one customer.
Throughout this volume you'll practice in a live SQLite database that runs entirely in your browser. It always starts with two small tables — customers and orders — so every example is repeatable. Let's meet them. Click Run:
Click Run to execute the query.
Five customers, four columns each: id, name, city, age. Now the other table:
Click Run to execute the query.
Notice orders.customer_id — it holds the same values as customers.id. That shared value is how the two tables relate: order 1 belongs to customer 1 (Ada). We'll formalize that idea (keys) in the next chapters, but you can already see the relational model's core trick — data is split into focused tables, then reconnected on demand.
Analogy Think of a spreadsheet workbook. Each sheet is a table; each row is a record; each column is a field. A relational database is that workbook — but with a strict type for every column, rules that reject bad data, the ability to find any row instantly, and a query language far more powerful than any spreadsheet formula. It's a spreadsheet that grew up and went to work for a bank.
SQL: asking questions
SQL (Structured Query Language) is how you talk to a relational database. You don't tell it how to loop through rows — you declare what you want, and the engine's query planner decides how to deliver it. A first real question: which customers are in Lagos?
Click Run to execute the query.
You asked for two columns, from one table, filtered to one city — and got exactly that, without writing a single loop. That is the whole spirit of SQL: describe the result, not the procedure.
SQL statements fall into a few families you'll meet across this volume:
| Family | Stands for | Example statements | Covered in |
|---|---|---|---|
| DQL | Data Query | SELECT |
Parts II–III |
| DML | Data Manipulation | INSERT, UPDATE, DELETE |
Part V |
| DDL | Data Definition | CREATE, ALTER, DROP |
Part IV |
| DCL / TCL | Control / Transactions | GRANT, COMMIT, ROLLBACK |
Parts V, VIII |
In production The database is almost always the hardest part of a system to scale and the most catastrophic to get wrong. You can restart a crashed web server and lose nothing; lose or corrupt the database and you may lose the business. That's why databases obsess over durability and integrity, why companies run dedicated database teams, and why "can you write good SQL and design a sane schema?" is a standard interview filter. Compute is cheap and stateless; state is precious.
Relational isn't the only kind
Relational/SQL databases (SQLite, PostgreSQL, MySQL, SQL Server, Oracle) dominate, but they aren't the only option. NoSQL systems — document stores (MongoDB), key-value stores (Redis), wide-column (Cassandra), and graph databases (Neo4j) — trade some of the relational guarantees for other strengths like flexible schemas or extreme scale. We devote Part VII to them. For now, hold this: relational is the default you should reach for until you have a specific reason not to — and understanding it deeply makes every other data system easier to learn.
Common Mistakes
- Treating the database as "just storage." It's an active guardian of correctness — constraints, transactions, and types are features to lean on, not bureaucracy to route around.
- Putting business rules only in application code. If three services write to a table, a rule enforced in one app is a rule not enforced. Integrity belongs in the database too.
- Reaching for NoSQL because it sounds modern. Most apps want relational guarantees; "web scale" is a problem you should be lucky enough to earn first.
- Never learning SQL properly. Hiding behind an ORM until it generates a query you can't read or fix is one of the most common ways engineers get stuck. This volume fixes that.
Think about it Imagine two people buy the last concert ticket at the same instant, and your "database" is a JSON file each server reads, edits, and writes back. What could go wrong? List every failure you can think of — lost writes, corruption, double-selling. Every item on your list is a problem a real DBMS was built to prevent. Keep the list; we'll answer it properly in Part V (Transactions).
Hands-on Get your hands dirty with the two tables you'll use all volume. In the playground below, (1) run it as-is to list everyone; (2) change the filter to find customers in 'Abuja'; (3) change it to customers older than 30; (4) select only their name and city. Each is a one-line edit — the goal is to feel how changing the description changes the result.
Click Run to execute the query.
Summary
- A database is organized data; a DBMS is the engine that stores, protects, and queries it — solving fast lookup, concurrency, durability, relationships, and integrity that raw files can't.
- The relational model (Codd, 1970) organizes data into tables of typed columns and rows, reconnected on demand through shared values.
- SQL is declarative: you describe the result you want and the engine plans how to get it — one language for any question.
- Statements group into DQL/DML/DDL/TCL families you'll master across this volume.
- Relational is the sensible default; NoSQL (Part VII) trades guarantees for other strengths when you have a specific reason.
- State is precious — the database is the part of a system you most need to get right.
Next, we'll zoom in on the relational model itself — how tables, rows, columns, and the discipline of one-fact-per-place turn a pile of data into a dependable model of the world.
Editorial reflection There's a reason database skills compound over a career while framework skills expire. A database is a promise: what you wrote down will still be here, correct, when you come back for it. Learning to keep that promise — through types, constraints, transactions, and thoughtful design — is really learning to build software people can trust with the things that matter to them. Master the data layer, and you become the engineer teams rely on when the stakes are highest.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.