What are we trying to build?

Our shop sells a canvas tote. Its product number is 27, its price is 20 credits, and one is in stock. A program can hold those three facts in memory and show them on a product page. Why build anything more?

Imagine closing that program and opening it again. Unless it saved the facts somewhere, its new run has no record of them. Now imagine two purchases arriving together. Both might be told that the last tote is available. Storing a value is only the beginning of the problem.

This course follows those problems into a small database engine: the software that stores data, finds it, changes it, and enforces rules about those changes. We will first understand each operation from the outside, then build up its internal machinery.

Start with one request

The shop’s application handles things such as a product page and a checkout button. The database engine handles the stored facts. The application sends a request, and the engine returns a result or an error.

1. Application asks

   “What is the price of product 27?”

2. Engine finds the stored record

   Product 27 · Canvas tote · 20 credits · 1 in stock

3. Engine returns a result

   20 credits. The application can now display the price.

These roles need not run on different computers. An engine can be a library inside the application or a separate program that accepts requests. We will start inside one program, where we can inspect every step.

Give the engine a rule to keep

Suppose a successful purchase reduces stock from 1 to 0 and records an order. We want both changes to happen together. An order without a stock change might sell the same tote again. A stock change without an order leaves us unable to say who bought it.

For now, that is a requirement, not an explanation of how to implement it. Later lessons will introduce transactions to describe the required behavior, and recovery machinery to preserve it when work is interrupted.

We will also ask how much work a lookup performs. Looking through three products is easy. Looking through millions for every request may be expensive. That gives us a reason to study indexes later.

A quick starting check

You do not need SQL yet. You should be able to follow a short instruction such as “for each product, compare its number with 27; return the matching product.” The memory lesson will show that loop in code and explain its notation.

If a program displays “purchase successful,” then forgets the order when restarted, has it met the shop’s requirement?

Think through what the buyer was promised

No. The message told the buyer that the purchase had succeeded, but the stored state cannot support that claim after restart. We need to define what success promises and arrange storage so that the promise survives the failures we claim to handle.

Simply displaying a result proves that the program ran. It does not prove that the result was saved safely.

Our first step is smaller: represent the product facts clearly. The next page gives names to a table, a row, and a key, using this same shop.

Sources and the wider path

The learning path and source guide explains how the course draws on roadmap.sh, university courses, and engine documentation. Harvard’s introductory SQL notes provide another introduction to storing and querying data.