Subjects and lessons to explore.

Law

Databases & SQL · Foundations

Tables

8 min read 5 practice questions
7 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

A is the basic storage unit of a relational : a named collection of related data arranged in rows and columns, like a grid. Each holds one ; each holds one kind of fact. Every row in a table lines up the same way, because the columns are fixed and named. Good design gives each kind of thing — customers, orders, products — its own table, and tables connect through values they share. A table resembles a spreadsheet, but its rules are stricter.

Why this matters

Every database task — finding a record, updating one, combining data from two places — begins with knowing where the data lives, and the answer is always a table. Once you can see a table as a named grid with a single purpose, you can predict what belongs in it, notice when one table tries to hold too many kinds of things, and follow how tables connect through shared values. That same eye transfers to spreadsheets, analytics tools, and any program that stores records. The lessons that follow — rows, columns, primary keys, and SQL — assume you can picture the table first. Learn this one idea well and the rest of database work becomes a matter of organizing information, not memorizing commands.

The college version

What a table is

The working definition comes from W3Schools' SQL tutorial: a table is a collection of related data entries that consists of columns and rows. IBM's explainer says the same thing from the other direction — a relational database organizes data into rows and columns, which together form a table where the data points are related to each other. Notice what both definitions insist on: the data is related. A table is not a dumping ground; it holds facts that belong together, such as all the members of a club or all the bikes the club tracks. PostgreSQL's documentation puts the same idea in formal terms: a relation — its mathematical name — is essentially another word for table. Everything a database does, from finding data to changing it to connecting tables, happens to tables.

The anatomy of a table

A table has exactly two kinds of parts. Columns run down the table: each column is one kind of fact, with a name and a single , such as text or a number. Rows run across: each row is one record — one complete set of facts about a single item. PostgreSQL's tutorial states the rule precisely: each row of a given table has the same set of named columns, and each column is of a specific data type. That one sentence is the whole anatomy. Rows and columns each have their own lessons; here, one line each is enough to see the grid the table is built from.

One table per kind of thing

The organizing pattern of a well-designed database is simple: one table per kind of thing. IBM's example is a company with a customer table — columns for customer ID, company name, address, and industry — and a separate transaction table — transaction date, customer ID, amount, and payment method. Each kind of thing gets its own table, and the tables stay separate even though they are related. Consider an original example: Brightwood Bicycle Co-op. The shop keeps a Members table (member number, name, phone, join date), a Bikes table (bike number, member number, make, color), and a Repairs table (repair number, bike number, date, cost). Three kinds of things, three tables. The pattern scales: customers, orders, and products in a store; students, courses, and enrollments in a school.

Names and purpose

A table is created with a name, and that name should say what the table holds. PostgreSQL's tutorial introduces its examples by name — a weather table for daily readings, a cities table for cities and their locations — and W3Schools' example is simply the Customers table. The design intuition: a table has a name and a clear purpose. Members, not Data. Repairs, not Table1. A name that names the kind of thing tells everyone — including future-you — what belongs inside, what questions the table can answer, and what should be kept out. If you cannot give a table a clear name, you probably do not yet know what it is for.

Tables connect through shared values

Tables rarely sit alone. IBM's explainer makes the point directly: data is typically structured across multiple tables, which are joined through unique identifiers such as a primary key or a foreign key, and those identifiers express the relationships between tables. In the co-op example, the member number appears in Members and in Bikes; the bike number appears in Bikes and in Repairs. Those shared values are the bridges. The details of keys and relationships each have their own lessons — primary keys, foreign keys, and relationships are sibling topics — so here the idea fits in one sentence: separate tables link through values they have in common.

A table is not a spreadsheet

At a glance a table looks like a spreadsheet: a grid of rows and columns. The resemblance is real, and the differences are the point. A database table insists that every row share the same named columns, that each column hold one type of value, and — as PostgreSQL's documentation notes — that rows have no guaranteed order, though they can be sorted for display. A spreadsheet tolerates merged cells, blank rows, formatting, and free-form notes; a table does not. It trades flexibility for discipline, and that discipline is what lets a database find, match, and update records reliably and without ambiguity.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

A table is where a database keeps one kind of thing. Picture a grid: rows running across, columns running down. Each row is one item — one customer, one book, one repair job. Each column is one kind of fact about that item, like a name, a price, or a date. Every row lines up the same way because the columns are fixed and named. Give the table a name that says what it holds, keep one kind of thing per table, and connect tables through values they share. That is nearly all there is to tables at this level. The language used to create and search tables, SQL, gets its own lesson.

Picture it like this

Think of a table like a well-organized binder of index cards. Each section of the binder is one table: a section for members, a section for bikes, a section for repairs. Every card in a section has the same printed blanks — name, phone, join date — and each filled-in card is one row. When you need to connect a member to her bikes, you flip to the bikes section and match cards by the member number written on both.

Where the picture stops working

The binder comparison flatters tables. A binder forgives a card with a blank slot or a scribbled note; a database table refuses: every row must have the same named columns, each column holds one type of value, and rows have no built-in order. Also, nothing in a binder stops you from filing a recipe card in the members section, while a database enforces its rules automatically, every time data is added.

Worked example

Brightwood Bicycle Co-op keeps records for its members, and the owner starts with one table: Members, with columns for member number, name, phone, and join date. Each row is one member — row 104 is Priya Shah, 555-0134, joined 2026-03-14. The shop also tracks each bicycle as its own kind of thing, so a second table, Bikes, holds bike number, member number, make, and color. A member with two bikes appears once in Members and twice in Bikes; the member number is the shared value that connects the tables. Repairs need their own table too: repair number, bike number, date, and cost. When the owner asks which repairs belong to Priya's bike, she follows the shared values from table to table: find Priya's member number, find her bikes' numbers, find the repairs attached to them. Three kinds of things, three tables, and every link is a value the tables share.

Key takeaway

A table is the grid that holds a database: a named collection of related data arranged in rows and columns. Give each kind of thing its own table, name it for what it holds, and link tables through shared values — and remember the structure is stricter than a spreadsheet.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

What is a table in a relational database?

Choose an answer, then check it.
Question 2 of 3foundational

According to PostgreSQL's documentation, which statement about a table's structure is true?

Choose an answer, then check it.
Question 3 of 3intermediate

A community garden club wants to track its gardeners, its garden plots, and the harvest records for each plot. Following the one-table-per-kind-of-thing pattern, how many tables should the club's database use?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define a table as a named collection of related data arranged in rows and columns, using the working definition attributed to W3Schools.
  • Identify rows and columns as the two structural parts of a table and state what each one holds.
  • Apply the one-table-per-kind-of-thing pattern by deciding how many tables a new scenario needs.
  • Distinguish a database table from a spreadsheet by the stricter rules tables follow.
  • Recognize that separate tables connect through shared values, with keys and relationships covered in their own lessons.

Common mistakes

  • Putting every kind of thing into one giant table.

    A members-and-bikes table would repeat the member's phone and join date on every bike row. Follow the one-table-per-kind-of-thing pattern instead: separate tables for members and bikes, connected by the member number.

  • Assuming rows keep the order you added them.

    PostgreSQL's documentation is explicit that SQL does not guarantee the order of rows within a table. Sorting happens when data is retrieved or displayed, not by the order rows were inserted.

  • Naming tables vaguely — Data, Stuff, Table1.

    A table's name should state its purpose, like Customers, Members, or Repairs. If you cannot name it clearly, you likely do not yet know what the table is for.

  • Treating a database table like a spreadsheet range.

    A spreadsheet tolerates merged cells, blank rows, and free-form notes; a database table requires the same named columns in every row, one data type per column, and rows without guaranteed order. The stricter rules are what make reliable lookups possible.

Easily confused

A database table vs. A spreadsheet range

Both are grids of rows and columns, but a table enforces fixed named columns, one data type per column, and unordered rows, while a spreadsheet allows merged cells, blank rows, and free-form content.

A row vs. A column

A row runs across the table and holds one complete record — one item; a column runs down and holds one kind of fact shared by every row.

One table per kind of thing vs. One table for everything

Separate tables keep each record's facts together and connect through shared values; a single oversized table repeats information and makes updates error-prone.

Key vocabulary

table
A named collection of related data arranged in rows and columns; the basic storage unit of a relational database.
row
One record in a table — the horizontal line of values that describes a single item.
column
One kind of fact held by every row in a table, identified by a name and a data type.
record
Another word for a row: one complete set of values describing a single item.
database
An organized collection of data, usually stored and managed by dedicated software.
data type
The kind of value a column holds, such as text, a whole number, or a date.
shared value
A piece of data that appears in more than one table, such as a member number, used to connect related records across tables.

Sources & references

  1. PostgreSQL Documentation 18: Chapter 2. The SQL Language — 2.2. Concepts — The PostgreSQL Global Development Group
  2. PostgreSQL Documentation 18: Chapter 2. The SQL Language — 2.3. Creating a New Table — The PostgreSQL Global Development Group
  3. SQL Introduction — W3Schools
  4. What is a relational database? (IBM Think explainer) — IBM

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Researched 2026-08-21

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.