Imagine we are preparing a database for a small online store. For now, it only needs users, products, and orders. This dataset is rich enough for common SQL tasks without introducing distracting business complexity. Its three main tables are users, products, and orders.
You do not need to create the tables yet; CREATE TABLE comes later. First become familiar with the records, because future queries, updates, joins, and statistics will all use them.
users: who uses the store
users stores an ID, name, email address, and city. The id is unique for each person. Later, this table can answer “Who lives in Tokyo?”, be sorted by name, or have an email updated.
| id | name | city | |
|---|---|---|---|
| 1 | Alice | alice@example.com | Tokyo |
| 2 | Bob | bob@example.com | Osaka |
| 3 | Chris | chris@example.com | Tokyo |
| 4 | Diana | diana@example.com | Kyoto |
products: what the store sells
products stores items with different prices and categories. Later it can answer “Which products cost more than 50?”, “Which is most expensive?”, “How many are Electronics?”, and “What is the average price in each category?”
| id | name | price | category |
|---|---|---|---|
| 1 | Keyboard | 80.00 | Electronics |
| 2 | Mouse | 40.00 | Electronics |
| 3 | Coffee Mug | 15.00 | Home |
| 4 | Backpack | 60.00 | Fashion |
orders: who bought what
orders does not repeat user names and product names. It refers to rows in the other tables using IDs. user_id says who ordered, product_id says what they bought, quantity stores how many, and order_date stores when.
| id | user_id | product_id | quantity | order_date |
|---|---|---|---|---|
| 1 | 1 | 2 | 1 | 2026-08-01 |
| 2 | 1 | 3 | 2 | 2026-08-03 |
| 3 | 2 | 1 | 1 | 2026-08-05 |
| 4 | 3 | 4 | 1 | 2026-08-06 |
Trace the first order by its IDs: user_id = 1 points to Alice, product_id = 2 points to Mouse, and quantity = 1. The row means “Alice bought one Mouse” even though orders does not repeat either name.
Assemble an order relationship
Take one record from users and one from products, then place them in the order slots (drag or click). Choose a quantity and write the relationship to orders. Try any combination, and remove orders to see each table's responsibility.
0 rows
Choose a user and product, then insert an order that stores only IDs.Why not store the names directly?
User and product names can change, and one person may have many orders. If Alice changes her name, a duplicated-name design requires editing many historical orders; a renamed product creates the same problem. A common design keeps official user data in users, official product data in products, and only user_id and product_id in orders. Later, JOIN will reconnect them when full information is needed.
View the three tables with SELECT
Assuming the tables exist, SELECT is the simplest way to inspect them. The asterisk means every column, so the first statement reads “return every column from users.”
SELECT * FROM users;
SELECT * FROM products;
SELECT * FROM orders;Visual tools and a practice database
Learning SQL does not mean living in a terminal. Developers often use visual tools to browse tables, write SQL, and inspect results. Their layouts usually share the same idea: databases, schemas, and tables on one side, an SQL editor in the center, and query results below. You only need to open a database, view tables, and execute SQL.
Common tools include DBeaver, DataGrip, MySQL Workbench, pgAdmin, and SQL Server Management Studio.
For basic SQL practice, SQLite is a friendly starting point: an entire database can live in one file with no separate server. If your class, company, or project already provides MySQL, PostgreSQL, or SQL Server, use that instead; this course favors portable SQL concepts.
KNOWLEDGE QUIZ
Inspect the store data
Write three SQL statements that show every column from users, products, and orders. Then use the tables to explain who placed order id 2, what was bought, and the quantity. Acceptance criteria: all statements end in semicolons, and the explanation shows how both IDs lead to names.