Exercise 1: Composite Indexes vs. SQL's Multi-Column Query — Possible Solution
====================================================================

WHAT A COMPOSITE INDEX IS
------------------------------
A composite index is a pre-built index structure Firestore requires when a query combines filters on more than one field in certain ways - in this chapter's case, an equality filter on status and a range filter on expiryDate. Firestore automatically maintains a single-field index for every field, but a query spanning two fields like this needs an index specifically built for that combination, declared ahead of time.

WHY THIS CHAPTER'S OWN QUERY NEEDS ONE
------------------------------
Because getExpiringSoonItems combines where("status", "==", "active") with where("expiryDate", "<=", threshold) - an equality filter and a range filter on two different fields - Firestore refuses to run it until the matching composite index has been created, either via the console link in the error message or a firestore.indexes.json file.

HOW SQL HANDLES THE EQUIVALENT QUERY DIFFERENTLY
------------------------------
Per this chapter, an unindexed multi-column WHERE clause in SQL still executes - it just runs slower, via a full table scan, rather than refusing outright. SQL treats a missing index as a performance problem the query planner works around; Firestore treats it as a query it simply won't attempt to serve at all until the required index exists.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly defines a composite index, correctly explains why this specific query (equality + range filter on two different fields) triggers the requirement, and correctly contrasts Firestore's refuse-until-indexed behavior with SQL's slower-but-still-runs approach to the same situation.