Understanding SQL Tables, Rows, Columns, and Keys

For many beginners, the hardest part of learning SQL is not SELECT. It is the moment when a tutorial starts talking about tables and the words still feel abstract. If you do not yet have a clear mental picture of what a table is, a statement like FROM customers feels more like magic syntax than a useful instruction.

That is why this first post in the series starts before query writing. We are going to make tables, rows, columns, primary keys, and foreign keys feel concrete. Once that picture is clear, writing queries and doing analysis becomes much easier.

Throughout this series, we will use one small ecommerce example: customers place orders, orders contain items, and items point to products. It is realistic enough to feel useful, but small enough to stay beginner-friendly.

Why do tables feel so abstract at first?

Because many people first meet databases as vocabulary instead of as an information system. You are told to memorize terms before you understand what problem those terms solve.

So forget SQL for a moment and think about the paper version of a business. If you ran a small shop, you might keep one record for customers, one for products, and one for orders. Each page would store a specific kind of information. A database is doing the same thing, just in a structured way that makes the information searchable and connectable.

Once you see it that way, the core terms become less intimidating:

• A table is a collection of records about one kind of thing.
• A row is one specific record.
• A column is one attribute recorded for every row.
• A key helps identify a record or connect it to another record.

In other words, databases do not start with SQL syntax. They start with the question, "What do we need to record, and how should we organize it?"

Think of a table as a structured record book

In our ecommerce example, we want to answer questions like "Who bought what?" That means we need to store at least four kinds of information:

1. Who the customers are.
2. Which products exist.
3. When an order happened.
4. Which products and quantities belong to each order.

You could try to stuff all of that into one giant table, but it would quickly become repetitive and messy. Instead, a relational database breaks that information into focused tables such as customers, products, orders, and order_items. Each table handles one kind of entity or relationship.

Here is the overall shape of that world:

If you cannot read every detail yet, that is fine. The important idea is that these tables are not isolated spreadsheets. Together, they describe one business world.

What are rows, columns, primary keys, and foreign keys?

Start with columns. A column defines one way to describe an object. In the customers table, we use customer_id, customer_name, and city to describe a customer. You can think of columns as the fixed questions every row must answer.

Rows are the answers. A row such as (1, 'Lina', 'Shanghai') means there is a specific customer whose ID is 1, whose name is Lina, and whose city is Shanghai. When you read a table, it helps to see one row as one entity, not as a bunch of unrelated cells.

Now for the primary key. A primary key gives each row a stable identity. Names can change. Product labels can be inconsistent. Cities can repeat. But a well-designed ID like customer_id or product_id gives the database a reliable way to point to exactly one row.

That matters because relational databases are built on accurate relationships. If you cannot uniquely identify a row, it becomes much harder to connect data safely.

That leads to foreign keys. In design terms, a foreign key is a column whose value points to a row in another table. For example, orders.customer_id tells us which customer placed the order. order_items.product_id tells us which product appears in that order line.

A simple way to remember the difference is this:

• A primary key answers, "Who are you?"
• A foreign key answers, "Who are you related to?"

Once that idea clicks, joins stop feeling like a trick and start feeling like a natural way to reconnect related records.

Before you learn join syntax, it helps to see this as a data-model pattern: one customer row can connect to several order rows because the orders table keeps the customer reference in a separate column.

The repeated customer_id values in the orders table are what make the one-to-many relationship visible: customer 1 appears once on the left but connects to multiple order rows on the right.

Look at the tables in the Playground

The fastest way to make these ideas feel real is to inspect actual data. The snippet below creates four small tables. Start by running the default query to look at the customers table. Then change the table name to products, orders, and order_items so you can see what each table is responsible for.

You can also try these quick checks:

SELECT *
FROM b1_products;

SELECT *
FROM b1_orders;

SELECT *
FROM b1_items;

After you look at all four tables, one important pattern should stand out: the database does not keep the entire order in a single row. It stores different layers of information separately and reconnects them through keys. That is the starting point of relational thinking.

Three beginner mistakes to avoid

The first mistake is treating a column as if it were just a label on a grid. A column is actually part of the data model. It defines the kind of information every row in that table must provide.

The second mistake is underestimating the role of primary keys. It is tempting to use names as identifiers, but names can repeat, change, or be entered inconsistently. Stable IDs are what make accurate relationships possible.

The third mistake is assuming a foreign key is just duplicated data. It is not. When orders stores customer_id, it is telling the database that each order belongs to a customer. Later, joins use that relationship to put the story back together.

Wrap-up: understand the tables first, then SQL gets easier

You have not learned much syntax yet, and that is the point. The foundation of SQL is not memorizing clauses. It is understanding how a database organizes real-world entities and relationships.

Once that picture is solid, query writing becomes far less mysterious because you know what SELECT is actually selecting from.

In the next post, we will keep using the same dataset and write your first real queries step by step, moving from SELECT and WHERE all the way to GROUP BY. Continue with Writing Your First Real SQL Query: From SELECT to GROUP BY.