In this episode you will
- Describe tables, rows, columns and keys
- Read a schema and predict what it can answer
Every spreadsheet you have ever used is secretly trying to be a database. It just never had the discipline. In this episode we look at what a relational database actually stores, and why that structure means you can ask it almost any question in a single sentence.
Part 1
A database is a set of tables
A relational database stores data in tables. Each table describes one kind of thing: customers, orders, products.
A table has columns, which define the attributes every record has (name, email, signup date), and rows, which are individual records. One row in a customers table is one customer.
The discipline that spreadsheets lack is this: every value in a column has the same type. A signup_date column only holds dates. That consistency is what lets the database answer questions quickly and correctly.
Part 2
Keys: how rows find each other
Every well-designed table has a primary key, a column whose value is unique for each row, usually called id. It is the row's permanent address.
Tables connect through foreign keys. An orders table has a customer_id column that holds the id of the customer who placed the order. Instead of copying the customer's name onto every order, the order simply points to the customer.
- Primary key: who am I?
- Foreign key: who do I belong to?
This is why the model is called relational: the relationships live in the data itself.
Part 3
SQL is a question, not a procedure
SQL (Structured Query Language) is declarative. You describe the result you want, and the database works out how to get it. You never write loops or tell it which rows to read first.
That is a big shift if you are used to spreadsheets, where you build the answer cell by cell. In SQL, a question like which customers in Canada signed up this year? is a single statement. The rest of this season teaches you how to phrase those statements.
Reading a schema
Here is a small schema for an online shop:
customers(id, name, country, signup_date)
orders(id, customer_id, total, ordered_at)
Without writing any SQL yet, we can already reason about what it can answer:
- How many customers are in Canada? Yes:
customershas acountrycolumn. - What did each customer spend in total? Yes:
orders.customer_idlinks each order to a customer, andorders.totalholds the amount. - Which product sells best? No: there is no products table, and orders don't record products.
Reading a schema this way, asking which table holds this, and how does it connect?, is the first step of every query you'll write.
Written by Edusodes editors.Researched and written by our editorial team.
Key takeaways
- 1A relational database stores data in tables of rows and typed columns.
- 2A primary key uniquely identifies a row; a foreign key points to a row in another table.
- 3SQL is declarative: you describe the result, the database decides how to compute it.
- 4Before writing a query, read the schema and ask which tables hold the answer.
Check your understanding
Episode quiz
Answer all 3 questions to continue.
Continue the season
Save your progress and unlock episode 2.
A free account tracks your quiz results and streak, releases the next episode on schedule and brings questions back for review after about 3, 10 and 30 days.