Exercise 2: 30 Books, 4 Distinct Authors — Possible Solution
====================================================================

APPLYING THE CHAPTER'S OWN REAL PATTERN
------------------------------------------------
The chapter's own quoted Rails example, for 10 books, generated exactly
two real SQL statements:

    SELECT books.* FROM books LIMIT 10
    SELECT authors.* FROM authors WHERE authors.id IN (1,2,3,4,5,6,7,8,9,10)

The first statement's own LIMIT tracks the number of BOOKS being
fetched. The second statement's own IN list tracks something
genuinely different -- not the book count, but the set of author ids
actually referenced by those books.

THE TWO REAL STATEMENTS FOR 30 BOOKS, 4 DISTINCT AUTHORS
------------------------------------------------------------
    SELECT books.* FROM books LIMIT 30
    SELECT authors.* FROM authors WHERE authors.id IN (1,2,3,4)

(The exact 4 id values depend on which specific authors those 30 books
actually reference -- (1,2,3,4) stands in for whichever 4 real author
ids appear at least once among the 30 fetched books.)

WHY THE IN CLAUSE HOLDS 4 VALUES, NOT 30
------------------------------------------------------------
Eager loading's whole real purpose, per the chapter's own quoted
finding, is to fetch each DISTINCT related row exactly once, no matter
how many parent rows reference it. Rails' own includes(:author)
mechanism collects the unique author_id values off the 30 already-
fetched books first, then issues one query asking for exactly those
rows -- not one query per book, and not one placeholder per book
either. If 30 books happen to share only 4 real authors between them,
querying for 30 id values would be genuinely wasteful: the database
would be asked to look up the same handful of rows repeatedly, several
times each, for no real benefit. The IN clause's own size scales with
the number of DISTINCT related rows actually needed, which is a real,
independent quantity from the number of parent rows that reference
them -- confirmed directly by the chapter's own 10-books-example
already using a 10-value IN clause purely because all 10 books in that
specific worked example happened to have 10 different authors, not
because "one value per book" is the real rule.

THE GENERAL PRINCIPLE, STATED DIRECTLY
------------------------------------------------------------
Query 1's own row count tracks the parent objects being loaded. Query
2's own IN-clause size tracks the distinct related objects those
parents actually reference -- which can be smaller than, equal to, or
(if a parent references more than one related row, as in a many-to-
many relationship) genuinely larger than the parent count, but is
never simply "the same number" by coincidence -- it's always exactly
the count of distinct ids actually needed.

WHY THIS WORKS AS AN ANSWER
----------------------------
It follows the chapter's own real, quoted SQL pattern exactly rather
than guessing at new syntax, correctly distinguishes what each of the
two real statements' own row/value counts actually track, and explains
the underlying reason (deduplication, not "one query slot per parent
row") using the chapter's own real 10-books-10-authors example as the
baseline it's generalizing from.