Exercise 1: Why No ORM, and What Gets Given Up — Possible Solution
====================================================================

WHY THIS COURSE USES better-sqlite3 DIRECTLY
------------------------------
Node's ecosystem has no single dominant default ORM the way Django has its own built-in ORM for Python - several competing options exist (Prisma, Sequelize, Drizzle, Knex), each with real adoption but none as clearly "the obvious choice." Rather than pick somewhat arbitrarily among them, this course writes raw SQL directly via better-sqlite3, keeping every query fully transparent with nothing generated or hidden behind an abstraction layer.

THE CONCRETE CAPABILITY GIVEN UP
------------------------------
Django's own migration system (makemigrations/migrate) tracks every schema change as a versioned, reversible file with a full history of what changed and when. This course has no equivalent - any future schema change requires hand-writing and manually running an ALTER TABLE statement, with no built-in record of the change at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains the reasoning behind skipping an ORM (no single dominant Node default, avoiding an arbitrary pick, transparency), and correctly names Django's migration system specifically as the concrete capability this course does without.