Premier League Predictor: FastAPI & PostgreSQL — Chapter 9, Exercise 1
====================================================

TASK
Explain why survivors is computed as old_table[:-RELEGATION_COUNT]
rather than by querying the database a second time for "every team
except the bottom three," and what real guarantee this relies on from
compute_league_table.

SOLUTION

old_table already IS the full, correctly-ranked 20-team standings,
returned by compute_league_table in exactly the real sort order
Chapter 7 established: points DESC, goal_difference DESC, goals_for
DESC, team name ASC. Because that ordering is guaranteed by the SQL
query's own ORDER BY clause, the last three entries in old_table are
guaranteed to be the actual bottom three teams by real standing —
there's no need to go back to the database and ask a second,
differently-phrased question, since the answer is already sitting in
the list this route already has in memory. old_table[:-3] is simply
"every row except the last three," which — given the guaranteed
ordering — is exactly "every team except the relegated three."

Querying the database a second time for "every team except the bottom
three" would require independently re-deriving which teams count as
"the bottom three" in that second query too — either duplicating the
same ranking logic in a different form, or trusting a separate query to
agree with the first one. Slicing the already-correctly-ordered
old_table avoids that duplication entirely and guarantees the two
concepts (bottom three, survivors) can never disagree with each other,
since they're both derived from the exact same single, already-fetched,
already-ordered list.

The real guarantee this relies on is that compute_league_table's own
ORDER BY is correct and consistently applied — if that ordering were
ever wrong or non-deterministic, the slicing here would silently
misidentify who's actually relegated, since nothing in rollover_season
independently re-verifies the ranking itself.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains precisely why list slicing is valid here (the list is
already correctly ordered by a query whose ORDER BY is trusted), why
re-querying would be both redundant and risk disagreement between two
separately-derived answers, and names the specific real guarantee
(correct, consistent ordering from compute_league_table) the whole
approach depends on.