Databases

Your program forgets everything when it closes. A database is the notebook it writes things down in — one that stays organized and lets many people read it at once.

Data lives in tables — rows and columns, like a spreadsheet with rules. The trick is linking tables by id instead of copying details everywhere.

SQL is how you talk to a database. You describe WHAT you want — not how to fetch it — and the database figures out the rest.

One rule: store each fact in exactly one place, never copy it. Splitting a messy repeating table into tidy linked tables stops the data from disagreeing with itself.

A primary key names each row uniquely; a foreign key points one table at another. Together they wire tables into the three shapes: one-to-many, many-to-many, one-to-one.

A join glues two tables together by matching ids — so you can show each order WITH the buyer's name. INNER keeps only matches; LEFT keeps everything on the left, filling blanks.

A transaction groups several steps so they ALL happen or NONE do. The four letters — ACID — are the promises that keep your data correct even when the power dies mid-update.

The 'I' in ACID is a dial. Crank it up and transactions never see each other's mess (safe but slow); turn it down and they go faster but can read half-done or shifting data.

HOW the database stops two writers from clobbering each other. Two playbooks: locking (grab the row, others wait) and MVCC (everyone edits their own snapshot, conflicts checked at commit).

Two transactions each hold a lock the other needs — both stuck forever. The database spots the wait-for cycle and breaks it by killing one transaction (the 'victim') and rolling it back.

An index isn't just a sorted list — it's a B-tree: a short, bushy, always-balanced tree where finding a row touches only a few levels, even over a billion rows.

You write WHAT you want; the database figures out HOW. It turns your SELECT into a step-by-step plan and picks the cheapest path to the answer.

Strict tables with strong guarantees, or flexible documents that scale wide? Not 'which is better' — a real decision about your data.

Model a tiny social app end to end — users, posts, likes, follows — and watch every key, relationship, and index you learned snap into place.