What Is a Database?
By the end of this lesson
Explain what a relational database gives you that a file does not.
A database is software whose job is storing data safely and answering questions about it quickly.
You could store records in a text file. People do, and it works until roughly the moment two users try to write at once, or you need to find one record among a million, or the power fails halfway through an update.
What a database provides that a file does not:
- Structure it enforces
- You declare that a price is a number and cannot be missing, and the database refuses anything else. A file will happily store the word "banana" in your price column.
- Fast lookup at scale
- With an index, finding one row among millions takes a fraction of a second. Scanning a file means reading all of it.
- Safe concurrent access
- Many users read and write simultaneously without corrupting each other's work. Coordinating that yourself is genuinely difficult.
- All-or-nothing changes
- A transaction either completes fully or not at all. Transferring money between accounts cannot leave one side updated and the other not.
- Relationships it understands
- An order belongs to a customer, and the database can enforce that the customer actually exists.
Why "relational"
Data is held in tables. A table is rows and columns, much like a spreadsheet, but with rules about what each column may contain.
The relational part is that tables reference each other. Rather than repeating a customer's full details on every order, you store the customer once and have each order point at them. Update the address in one place and every order reflects it.
The duplication problem, concretely:
| Everything in one table | Separate, related tables | |
|---|---|---|
| Customer address stored | Once per order | Once per customer |
| Changing an address | Update every order for that customer | Update one row |
| Risk of inconsistency | High — some rows get missed | Low — there is only one copy |
| Finding a customer's orders | Match on repeated text, unreliably | Match on a stable identifier |
One more thing worth knowing early: relational databases are not the only kind. Document databases, key-value stores and others exist and suit particular problems. Relational remains the default for business applications because most business data genuinely is relational, and the guarantees around transactions are hard to give up.
Summary
- A database enforces structure, finds data quickly, and coordinates concurrent access
- Transactions make related changes all-or-nothing
- Relational means tables reference each other rather than duplicating data
- Most data bugs and slow pages trace back to schema design or queries
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
A small shop tracks orders in a spreadsheet, with the customer's name, phone number and address typed into each row. What goes wrong as this grows, and which problems would separate tables solve?
Show solution
Addresses drift out of sync because updating means finding every row for that customer. Names get typed inconsistently, so "R. Sharma" and "Ravi Sharma" look like two people. Counting distinct customers becomes guesswork.
Separate tables fix all three: the customer exists once, is referenced by a stable identifier, and counting customers becomes counting rows in one table.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.