An organised, structured collection of data that can be searched and updated efficiently

In a database table, what is a record?

One row — all the stored information about one entity, such as one student

One column — a single category of data, such as "date of birth"

A grassy area outside the data centre

Why does every record need a primary key?

A unique identifier tells records apart, even when other details (like names) are identical

To make the table look complete

Primary keys are optional decoration

A request for specific data from a database, such as "all students born before 2010"

Why is a database better than a giant spreadsheet when MANY people need the data at once?

Databases handle many simultaneous users safely, keeping the data consistent

Spreadsheets cannot store more than 100 rows

A school stores each student's details ONCE, and class lists point to student IDs. What problem does this design avoid?

The same student's details being stored in many places and drifting out of date

Students being taught mathematics

Teachers knowing students' names

Select ALL systems that almost certainly run on a database.

An online shop's product catalogue and orders

A school's student information system

A game's player accounts and high scores

Databases and Records

⏱ 8 min✏️ Quiz at the end

Data With a Filing System

A list holds values in order — fine for thirty scores. Now try a school: 1,200 students, each with a name, date of birth, class, emergency contact… and the office needs "every Year 8 student with no photo consent" by lunchtime. A pile of documents won't answer that. Even one giant spreadsheet groans. This is the job databases were invented for: storing structured data so it can be searched, updated, and trusted — fast, and by many people at once.

Databases run the world more than any other software: every shop, bank, hospital, game server, and website with an account system has one underneath.

Tables, Records, Fields

The core arrangement is the table — data organised like a well-designed register:

StudentID	Name	DateOfBirth	Class
1001	Aisha Khan	2012-03-14	8A
1002	Sam Lee	2011-11-02	8B
1003	Sam Lee	2012-07-19	8A

Each row is a record: everything stored about one entity (one student).
Each column is a field: one category of data, with a consistent type (text, number, date, Boolean) — the same discipline as variables having types.

Notice the two Sam Lees — a real situation names cannot untangle. Hence the first column: StudentID, the primary key, a value guaranteed unique per record. Keys are how records are told apart, pointed at, and connected. When your school, doctor, and library each assign you a number, this is why.

Queries: Asking Questions of Data

A database's superpower is the query — a precise question the engine answers by finding every matching record:

FIND students WHERE Class = "8A" AND DateOfBirth < 2012-06-01

The conditions are pure Boolean logic applied to fields. Queries also update (change Aisha's class to 8C), insert new records, and delete old ones. (Real systems write these in a language called SQL — the pseudocode above is close in spirit to the real thing.)

Speed is the striking part: millions of records, answers in milliseconds. Databases earn this with indexes — internally sorted lookup structures that let the engine binary-search instead of scanning every row. Everything from this course's algorithms unit is being used in anger here.

One Fact, One Place

Good database design follows a rule worth learning young: store each fact exactly once. Suppose every class list stored each student's full name and contact details. Then a family moves house, and their details must be corrected in seven places… and will be, in six of them. Now the database contradicts itself, and nobody knows which record to trust.

Instead, details live once, in the students table; class lists store only StudentIDs pointing at them. Update one record and every class list is instantly right. Databases that link tables by keys like this are called relational — the design that has dominated for fifty years. (You have seen this failure pattern before: it is copy-paste code wearing a data costume, and the cure — one definition, many references — is identical.)

Many Hands, One Truth

The final superpower: concurrency. Hundreds of ticket-buyers hammer a booking site in the same second; the database ensures the last seat sells exactly once. It coordinates simultaneous reads and writes, keeps half-finished operations from corrupting data, and survives crashes with its records intact. A shared spreadsheet attempting that ends in tears — this reliability engineering is precisely what you are paying for (and why databases live on serious servers and get backed up religiously).

Try It Yourself

Design a table for a library's loans: which fields do you need, what type is each, and what is the primary key? Then write (in query-pseudocode) "all books due back before today that are still out". Trickier: loans need to point at both a book and a borrower — how?

Worked Example — Linking Two Tables With a Foreign Key

The library loans puzzle from the exercise above deserves a worked answer, because it introduces an idea used in almost every real database: linking one table to another. Suppose the library already has a Books table and a Borrowers table:

BookID	Title
B01	The Hobbit
B02	Wonder

BorrowerID	Name
U10	Priya
U11	Tom

A Loans table doesn't repeat the book title or borrower name — instead, it stores the keys that point back to the right row in each table:

LoanID	BookID	BorrowerID	DueDate
L001	B01	U10	2026-07-12
L002	B02	U11	2026-06-28

BookID and BorrowerID here are called foreign keys: a primary key from one table, reused in another table to create a link between them. This is precisely the "one fact, one place" principle from earlier in this lesson, extended across multiple tables rather than within just one — the book's title is stored exactly once, in Books, no matter how many times it has ever been borrowed. To answer "which books does Priya currently have?", the database follows the link: find Priya's BorrowerID (U10), find every Loans row with that BorrowerID, then follow each BookID back into the Books table to get the titles. This chaining of tables via keys is exactly what makes a database relational.

Key Words

Database — an organised collection of data built for querying and updating
Table / record / field — the grid / one row (one entity) / one column (one category)
Primary key — the unique identifier of each record
Query — a precise request to find, change, add, or remove records
Relational — a design linking tables together by keys, storing each fact once