Exercise 3: What Prisma Migrate Actually Solves — Possible Solution
====================================================================

THE PROBLEM WITH MANUAL ALTER TABLE STATEMENTS
------------------------------
In the sibling course, a schema change means writing an ALTER TABLE
statement by hand and applying it directly against the database, with
nothing tracking which changes have already been applied, in what order,
or on which environment (a developer's own machine, a teammate's
machine, a production server). If two people change the schema
differently at the same time, or a change is applied to one database but
forgotten on another, nothing in that setup catches the mismatch.

WHAT PRISMA MIGRATE ACTUALLY SOLVES
------------------------------
Prisma Migrate turns every schema change into a real, versioned migration
file, generated automatically by comparing the current schema.prisma
against the database's own migration history. Running npx prisma
migrate dev applies only the migrations a given database hasn't seen
yet, in the correct order, and records that they've been applied — so
two different databases (a laptop and a deployed server, for example)
can be brought to the exact same schema state reliably, and the full
history of how the schema got to its current shape is preserved as
actual files rather than living only in whoever's memory made each
change.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the real risk in the manual-ALTER-TABLE approach
(no tracking of what's been applied, where, or in what order) and
explains what Prisma Migrate concretely adds instead — versioned,
ordered, automatically-tracked migrations — rather than just restating
that "migrations exist" without saying what problem they solve.