What a Relational Database Actually Is

Before you write a single line of SQL, it helps to understand what a relational database actually is, and why it won this fight decades ago.

Tables Rows And Columns

A relational database stores data in tables. A table is just a grid, like a spreadsheet, with rows and columns. Each column has a name and holds one kind of value. Each row is one record. For example, a table called users might have columns id, name, and email, and a row like 1, Vikesh Singh, vikesh@example.com.

The word "relational" does not mean tables relate to each other like family. It comes from a mathematical idea: a "relation" is just a set of rows with the same structure. MySQL, PostgreSQL, SQLite, and Oracle are all relational database systems because they organize data this way and let you connect tables through shared values.

Why Split Data Into Tables

Why tables instead of one giant file? Because splitting data into tables avoids repeating the same information everywhere. Imagine you store every order with the customer's full name and email copied into each row. If Tony Stark changes his email, you would need to update hundreds of order rows. Instead, you keep one row for Tony Stark in a customers table, and orders only store his customer_id. This is the core idea you will keep seeing in this course: store a fact once, reference it everywhere else.

Here is a tiny example of two related tables:

CREATE TABLE customers (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100),
    email VARCHAR(150)
);

CREATE TABLE orders (
    id INT PRIMARY KEY AUTO_INCREMENT,
    customer_id INT,
    total DECIMAL(10,2)
);

The orders table does not repeat the customer's name or email. It just stores customer_id, a number that points back to a row in customers. That pointer is called a foreign key, and you will learn it properly in a later lesson. For now, just notice the shape: small, focused tables, connected by IDs.

A Common Design Mistake

A common beginner mistake is designing one huge table that tries to hold everything: customer info, order info, product info, all mixed into one wide table with lots of empty or repeated columns. It feels simpler at first, but it quickly becomes painful to update and full of duplicate data. Relational design trades a little extra typing now (writing JOINs later) for a lot less pain later (no duplicate, contradicting data).

Another beginner confusion: MySQL is the database system (the engine that stores and manages data), while SQL is the language you use to talk to it. You will install MySQL in the next lesson and start typing SQL commands against it. Different database systems (MySQL, PostgreSQL, SQL Server) all speak SQL, with small dialect differences, the way British and American English share most words but differ on some spelling.

Why does any of this matter practically? Because every decision you make later, how to split data into tables, which columns to add, which columns to link, comes back to this one idea: a relational database is a set of small, honest tables that reference each other instead of repeating themselves. Keep that in your head and the rest of this course will make a lot more sense.

Try It Yourself

Your turn: think of an app you use daily, like a food delivery app. List three things it probably tracks (users, restaurants, orders) and imagine which columns each table would need, and how they would reference each other by ID. You do not need MySQL installed yet, just paper and this way of thinking.