Exercise 1: Why the Deep URL Needs Only One Lookup — Possible Solution
====================================================================

THE DESIGN DECISION
------------------------------
Per Chapter 2, the Page model stores a precomputed, unique fullPath
column - the materialized-path half of the adjacency-list-plus-
materialized-path hybrid - alongside the parentId adjacency-list
column. fullPath already contains the complete, slash-joined path
string for every page, computed once at creation/move time, not
derived fresh on every read.

WHAT THIS MEANS FOR STEP 4
------------------------------
Visiting /programming/general-purpose-languages/java/fundamentals/
chapter-1 triggers Chapter 3's own catch-all route, which joins the
five URL segments into the identical string
"programming/general-purpose-languages/java/fundamentals/chapter-1"
and runs prisma.page.findUnique({ where: { fullPath } }) - a single
equality lookup against an already-stored, already-complete value.
Nothing about resolving this page requires walking up or down the
tree, or touching any other row at all.

WHY THE ALTERNATIVE (ADJACENCY LIST ALONE) WOULD HAVE NEEDED FIVE
------------------------------
Without the precomputed fullPath column, resolving this same URL would
require finding the deepest page by slug, then following parentId
links upward one row at a time to confirm the rest of the path matches
- or, working the other direction, five separate slug lookups walking
down from the root. Either way, exactly the five-query cost the
materialized-path half of Chapter 2's own hybrid design was chosen
specifically to avoid.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the precomputed fullPath column (not the
catch-all route itself, and not Prisma in general) as the actual reason
only one query is needed, and correctly explains what the cost would
have been without it - directly tracing the answer back to Chapter 2's
own explicit tree-representation-strategy comparison.