Exercise 3: Designing Enrolments — Possible Solution
======================================================

  model Student {
    id          Int          @id @default(autoincrement())
    name        String
    enrolments  Enrolment[]
  }

  model Course {
    id          Int          @id @default(autoincrement())
    title       String
    enrolments  Enrolment[]
  }

  model Enrolment {
    studentId   Int
    courseId    Int
    enrolledAt  DateTime     @default(now())
    completed   Boolean      @default(false)

    student     Student      @relation(fields: [studentId], references: [id], onDelete: Cascade)
    course      Course       @relation(fields: [courseId], references: [id], onDelete: Restrict)

    @@id([studentId, courseId])
    @@index([courseId])
  }

Why an implicit relation won't do:

The facts to record — when the student enrolled and whether they've
finished — belong to the *link* between a student and a course, not to
either one alone. An implicit many-to-many relation's join table only
holds the two IDs and can't store anything else, so these fields need
an explicit join model. (A natural name like "Enrolment" is often
clearer than "StudentCourse".)

Design choices:

  - @@id([studentId, courseId]) stops a student enrolling in the same
    course twice.
  - Deleting a student removes their enrolments (Cascade); deleting a
    course that still has enrolments is refused (Restrict), so records
    of students' learning aren't lost by accident.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies that the data describes the relationship itself — the
key sign that an explicit join model is needed — and makes deliberate
choices about uniqueness and deletion.