Relational Databases and Tables

A relational database stores data in tables: a grid of rows (also called records) and columns (also called fields or attributes), where each column has a fixed name and data type across the whole table.

users +----+---------+----------------------+ | id | name | email | +----+---------+----------------------+ | 1 | Ada | ada@example.com | | 2 | Grace | grace@example.com | +----+---------+----------------------+

This alone looks like a spreadsheet. What makes it relational is that tables reference each other through shared values, so data doesn't need to be duplicated across tables:

orders +----+---------+------------+ | id | user_id | total | +----+---------+------------+ | 1 | 1 | 42.00 | | 2 | 1 | 15.50 | | 3 | 2 | 99.99 | +----+---------+------------+

orders.user_id refers back to users.id — this is the relationship. Instead of repeating a customer's name and email on every one of their orders, each order just stores a reference to the user, and you connect the two tables when you need combined data (which is exactly what JOIN, covered a few lessons ahead, does).

Why split data across tables at all

The alternative — one giant table with every order row also repeating the customer's name, email, and address — creates real problems: update a customer's email and you'd have to change it in every order row that mentions them, and any row you miss leaves the data inconsistent. Splitting related data into separate tables, connected by reference rather than by duplication, is the core idea behind normalization, which gets a full lesson later in this course.

Schema: the structure, defined upfront

A table's schema is its definition — the column names, their data types, and any rules about what values are allowed (covered in the next couple of lessons). Unlike a spreadsheet, where any cell can hold anything, a relational database enforces this structure: you can't insert text into a column defined as a number, and (with constraints in place) you can't insert an order that references a user_id that doesn't exist.

Primary and foreign keys, briefly

Every table typically has a primary key — a column (often called id) that uniquely identifies each row — and other tables reference it through a foreign key, like orders.user_id referencing users.id. This pairing is central enough to relational databases that it gets its own dedicated lesson later in this course.

With the shape of the data established, the next lesson writes your first real queries: retrieving rows with SELECT.