Tables, rows, and columns

A relational database stores related facts in tables. A table should describe one kind of thing, such as a customer, order, or product.

Consider this orders table:

id	customer_email	status	total
101	ada@example.com	paid	49.00
102	lin@example.com	pending	18.50

Each horizontal row is one order. Each column describes one attribute shared by every order. The value at one row and column is sometimes called a field or cell.

The schema exists before the data. It says that id identifies the row, customer_email contains text, status accepts the chosen representation, and total stores an exact amount.

That structure lets SQL ask useful questions:

SELECT id, total
FROM orders
WHERE status = 'paid';

The result contains order 101, because that row makes the condition true.

A row needs a stable identity. Names and email addresses can change or repeat, so databases normally use a primary-key column such as id. The key lets an update target one order without depending on mutable business data.

Do not put several independent values into one cell. A comma-separated list of product IDs cannot be constrained or joined like real rows. Related facts belong in related tables, which we will model later.

Your action is to sketch a books table with four columns. Mark the primary key, choose one required column, and write two example rows. Then explain what one row represents.