Tables, Rows & Columns
The three building blocks of every database — and how to read a table like a pro.
You know databases store data in tables. Time to look inside one.
| id | name | age | |
|---|---|---|---|
| 1 | Alice Johnson | alice@example.com | 28 |
| 2 | Bob Smith | bob@example.com | 34 |
| 3 | Carol White | carol@example.com | 22 |
Three words unlock everything:
- A row is one complete record — one user, with all their info. This table has 3 rows.
- A column is one kind of information — every value in the
emailcolumn is an email. This table has 4 columns. - The table is the container: all your users, one row each.
| id | name | age | |
|---|---|---|---|
| 1 | Alice Johnson | alice@example.com | 28 |
| 2 | Bob Smith | bob@example.com | 34 |
| 3 | Carol White | carol@example.com | 22 |
In the users table above, what does row 2 represent?
- AOne complete record: everything we know about Bob Smith
- BAll the emails in the database
- CThe number 2
- DA column called 'Bob'
| id | name | age | |
|---|---|---|---|
| 1 | Alice Johnson | alice@example.com | 28 |
| 2 | Bob Smith | bob@example.com | 34 |
| 3 | Carol White | carol@example.com | 22 |
Still using the users table: you read down the 'age' column. What do you get?
- AThe same kind of value for every user: 28, 34, 22
- BEverything about Alice
- CThe table's name
- DA mix of names, emails, and ages
A table looks like a spreadsheet — but it's a spreadsheet with rules:
- Every row has the same columns. No user can have a secret extra column.
- Every column has a fixed kind of data. The
agecolumn holds numbers — the database will refuse the word"hello"there. - Rows have no built-in order. There's no 'row 5 comes after row 4' — you ask for the order you want, when you want it.
These rules sound strict. They're the point: because the structure is guaranteed, the database can answer questions about millions of rows at lightning speed, and bad data gets rejected automatically.
One database holds many tables — one per kind of thing. An online shop might have:
-- database: shop
users -- one row per customer
products -- one row per product
orders -- one row per order
reviews -- one row per reviewThat's the core design habit: one table per kind of thing, one row per thing. Don't mix products and customers into one mega-table — give each their own home, then connect them (that's what keys do — coming later this module).
- Naming convention — tables are named in the plural and lowercase
You're designing a database for a school: students, teachers, and courses. How should the tables look?
- AThree tables — students, teachers, courses — one row per person or course
- BOne giant 'school' table with everything mixed together
- COne table per student — 500 tables for 500 students
- DA single table with one row containing all the data
A products table has columns: id, name, price, stock. The shop adds a new product. What changes in the table?
- AOne new row is added — the columns stay exactly the same
- BOne new column is added
- CA new table is created for the product
- DThe price column is renamed