What Is a Database Table?

What Is a Database Table?

Most databases (systems that organize and store data) keep their data in this form.

A row is one record, a column is one field

Picture a paper daily work report (article in Japanese).

The date, the person, the type of work, and the hours line up as columns.

Date	Person	Work type	Hours

You write one entry on one line, and the next entry goes on the line below. That is the shape of a table.

No.	Date	Person	Work type	Hours
1	Nov 4	Sato	Inspection	3.5
2	Nov 4	Suzuki	Packing	2.0
3	Nov 5	Sato	Packing	4.0

A row is also called a record.

A column is also called a field.

How it differs from an Excel sheet

You can usually type anything into an Excel cell. Write “about 3 hours” in the hours box and nothing stops you.

A table is different. For each column, you decide in advance what may go in it (PostgreSQL documentation).

• A number column accepts only numbers.
• A date column accepts only what can be read as a date.
• A column that forbids blanks cannot be saved empty.

Data that breaks the rules is turned away at the door.

The value of a table lies in this strictness about what goes in.

The number that points to one row: the primary key

If there are two people named Sato, the name alone cannot tell you which row is which.

So each row gets a number that no other row has. This column is called the primary key.

Employee numbers and order numbers do exactly this job.

A primary key cannot hold duplicates or blanks.

A value that no other row shares is called unique.

The primary key is what lets you point and say, “this row.”

Split the tables, link them by number

Suppose every line of the report also listed the person’s department.

On top of each person’s name, you would write the same department name hundreds of times.

Report table (with departments written in)
1  Nov 4  Sato    Inspection  3.5
2  Nov 4  Suzuki  Shipping    2.0
3  Nov 5  Sato    Inspection  4.0
...

When someone transfers, all of those lines need fixing. Miss one, and the table contradicts itself.

So the people’s details move to a separate table. The report keeps only each person’s number.

This is the people table.

Person No.	Name	Department
101	Sato	Inspection
102	Suzuki	Shipping

This is the report table. The person box is now a number.

No.	Date	Person No.	Hours
1	Nov 4	101	3.5
2	Nov 4	102	2.0
3	Nov 5	101	4.0

Follow the number and you can read the two tables together: “Job 1 was done by Sato in Inspection.”

A column that points to a number in another table is called a foreign key. It cannot hold a number that table does not have (PostgreSQL documentation).

When someone transfers, you fix just one row in the people table.

People table (fix only this row)
101  Sato  Inspection
 |
 v
101  Sato  Shipping  <-- this changes

Report table (no change needed)
1  Nov 4  101  3.5
3  Nov 5  101  4.0

Takeaways

When you use one, it will feel cramped at first to be turned away because what may go in is decided in advance.

But tables have their own language for getting data out, SQL. Learn just that, and you will be saying, “Whoa, that’s fast!”

You are sure to be moved by how convenient it is.

More on SQL another time...

Trivia

• Relational database: a database that holds data in tables and links the tables by their values.
• SQL: the language for getting data in and out of tables.
• PostgreSQL: free relational database software.
• SQLite: a small relational database built into apps.
• UUID: a long number designed not to collide, even when created in separate places.

History

The beginning: you had to know where the data was

In the 1960s, the amount of data computers handled grew quickly (IBM, “The relational database”).

In 1968, a system built to track parts for the Apollo program went on sale as IBM’s IMS (IBM, “Information Management Systems”).

But databases of that era were tied to rigid parent-child structures and to the path to where data was stored.

Getting one piece of data could mean a specialist writing a whole program (IBM, “The relational database”).

The turning point: with tables, you need not know where data is

In 1970, IBM researcher Edgar Codd published the idea of holding data in tables that can be related to each other (Codd, “A Relational Model of Data for Large Shared Data Banks”).

Links between data would be expressed by the values inside it, not by where it was stored. That was the new part.

Link by the values inside, not by the place.

Theory alone left many doubters, so from 1973 IBM tested it in practice with System R (IBM, “The relational database”).

SQL, the language for getting data in and out of tables, grew up here too. In 1983, the DB2 product shipped (IBM, “The relational database”).

Development under way now

• In September 2025, PostgreSQL 18 was released. It added a way to create UUIDs, used as row numbers, in a form that is easier to search (PostgreSQL, September 25, 2025).
• pgvector, an extension that stores the lists of numbers AI works with (vectors) in the same table as other data, is under development (pgvector).

What comes next

Databases that hold data in tables now run even inside smartphones and browsers (SQLite, “Most Widely Deployed”).

The idea from 1970 is still the foundation. Whether the next 50 years will stay with tables, nobody knows yet.