Tables, Records and Fields

Almost every app you use is really sitting on top of a database — a huge, organised store of facts. Your school's system knows every pupil; a streaming service knows every film; an online shop knows every product it sells. But how is all that information actually laid out so a computer can search it, sort it and update it in a flash? The answer is beautifully simple: it's arranged in a table, exactly like a well-drawn spreadsheet.

A single table holds data about one type of thing — one table for pupils, a different table for books, another for teams. Get the anatomy of one table straight and you understand the foundation the whole subject is built on. There are just three words to nail: table, record and field.

A table, up close

Here is a small table called Pupil. It stores facts about pupils — and nothing else. Look at how it's shaped, then read the labels underneath.

Table: `Pupil`
PupilID	Surname	Forename	DateOfBirth	TutorGroup	FreeSchoolMeals
1024	Okafor	Aisha	2009-03-14	10B	true
1025	Byrne	Ben	2010-11-02	10B	false
1026	Adeyemi	Chloe	2009-07-21	10A	false
1027	Novak	Dev	2010-01-30	10A	true

The whole grid is the table. It describes one kind of thing here — pupils. Facts about books or classrooms would live in their own separate tables.
Each row is a record: everything the table knows about one pupil. The second row (1025, Byrne, Ben, …) is Ben's record, and Ben's alone. A record is sometimes called a row or a tuple.
Each column is a field: one attribute that every pupil has, such as Surname or DateOfBirth. A field is sometimes called a column or an attribute. The column heading is the field's name.

So a table is a grid of records (down) crossed with fields (across). One cell — say Chloe's TutorGroup — is the value of one field for one record.

Rows are records, columns are fields

This diagram peels the two directions apart so the pattern really sticks. Step through it: first the empty grid, then a highlighted record (a whole row), then a highlighted field (a whole column), then the single cell where they cross.

Reading across a row answers "tell me everything about this one pupil". Reading down a column answers "tell me this one fact about every pupil" — for example, list all the surnames, or find everyone in tutor group 10A. A database is powerful precisely because it can slice the same grid both ways.

Every field has a data type

When you design a table you don't just name each field — you also decide what kind of value it is allowed to hold. That choice is the field's data type. Picking the right type means the database can store the value efficiently, check that new data is sensible, and sort or calculate with it correctly. These are the everyday GCSE data types:

Common field data types
Data type	Holds	Example value	Field it suits
Text (string)	Letters, symbols, spaces	`Okafor`	`Surname`
Integer	A whole number	`1024`	`PupilID`
Real (decimal)	A number with a fractional part	`1.62`	`HeightInMetres`
Date/time	A calendar date or time	`2009-03-14`	`DateOfBirth`
Boolean	Exactly two values: true or false	`true`	`FreeSchoolMeals`

Choosing the type is a genuine design decision. A phone number looks like a number, but you'd store it as text — you never add phone numbers together, and storing it as an integer would throw away a leading zero (07… becomes 7…). Likewise, store money in a real or currency field, a "has the fee been paid?" answer as a boolean, and a birthday as a date (so the database can work out ages and sort chronologically instead of treating "12/03" as plain text).

A boolean field can only ever be true or false — two states — so it's tiny to store and impossible to fill in wrongly. If you used a text field instead, one person types Yes, another yes, a third Y and a fourth true. Now a search for everyone entitled to free school meals misses half of them, because the computer sees four different strings. A fixed, two-value type keeps the data clean and searchable — which is the whole point of putting it in a database.

How this connects to code you've met

You've already met this shape when you learned about records in programming: a table is really just an array of records. One record is one pupil; the fields are its named values; the table is the whole list of them. The database words are simply the names the data world uses for the same idea.

interface Pupil { // one field per line — like the table's columns pupilID: number; // Integer surname: string; // Text forename: string; // Text dateOfBirth: string; // Date tutorGroup: string; // Text freeSchoolMeals: boolean;// Boolean } // The table is an array of records — each element is one row. const pupilTable: Pupil[] = [ { pupilID: 1024, surname: "Okafor", forename: "Aisha", dateOfBirth: "2009-03-14", tutorGroup: "10B", freeSchoolMeals: true }, { pupilID: 1025, surname: "Byrne", forename: "Ben", dateOfBirth: "2010-11-02", tutorGroup: "10B", freeSchoolMeals: false }, ];

Notice the mapping: the interface lists the fields (with their data types), each { … } object is one record, and the array is the table. Same three ideas, dressed in database clothes.

The classic beginner's mistake is cramming several pieces of information into one field. Keep every field atomic — it should hold exactly one piece of information, and no more. Look at these two designs for the same data:

❌ Not atomic — several facts squashed together
PupilID	FullName	Contact
1024	Aisha Okafor	Okafor, 12 Elm Rd, aisha@…

✓ Atomic — one fact per field
PupilID	Forename	Surname	Street	Email
1024	Aisha	Okafor	12 Elm Rd	aisha@…

Why does it matter? If FullName holds "Aisha Okafor", you cannot cleanly sort the pupils by surname, or search for everyone called Okafor, without the computer clumsily hunting through the middle of the text. Splitting it into Forename and Surname makes both instant. The rule of thumb: if you might ever want to search, sort or count by a piece of information on its own, give it its own field. Split "full name" into forename and surname, and never stuff a list of several values (three phone numbers, say) into a single cell.