Exercise 1: Why a Pure Adjacency List and Nested Sets Were Both Ruled Out — Possible Solution
====================================================================

WHY A PURE ADJACENCY LIST WOULD MAKE RENDERING SLOW
------------------------------
Per this chapter's own comparison table, reading a full path from a pure adjacency list requires walking one parent link at a time, one query per level, to reconstruct a deep path. Since this site's own real traffic pattern is heavily read-weighted - pages get rendered constantly - every single page view would need multiple sequential database queries just to resolve which page is being requested, before any actual content could even be fetched. For a five-level-deep path like programming/general-purpose-languages/java/fundamentals/chapter-1, that's potentially five separate queries on every single page load, which is a real, direct cost on the operation that happens most often.

WHY NESTED SETS WERE RULED OUT FOR THE OPPOSITE REASON
------------------------------
Per this chapter, moving a subtree under nested sets is very slow, because nearly every other row's left/right values shift on any change. This site's own traffic profile is the mirror image of the adjacency-list problem: reads happen constantly, but reorganizing the tree happens rarely, by one admin, deliberately. Nested sets optimize heavily for exactly the operation (reads) this chapter says matters less relative to how rarely writes happen, while making the already-rare write operation punishingly expensive - the wrong tradeoff for this specific project's actual usage pattern.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that a pure adjacency list requires multiple sequential queries to resolve a deep path (bad for a read-heavy site), and correctly explains that nested sets impose a very expensive write cost on subtree moves (bad even though writes are rare, since when they do happen they'd be disproportionately costly) - tying both conclusions back to this chapter's own stated read-heavy, write-rare traffic profile.