Premier League Predictor: FastAPI & PostgreSQL — Chapter 3, Exercise 2
====================================================

TASK
Explain why add_team_to_season looks up an existing Team by name before
creating a new one, and describe a real scenario where skipping that
lookup would create a duplicate Team row for the same real club.

SOLUTION

Chapter 2 deliberately made Team rows permanent, independent of any
single season, precisely because a real club doesn't stop existing just
because it gets relegated. That design only actually pays off if the
app remembers to check for an already-existing Team row before creating
a new one — otherwise the same real club can end up represented by
multiple separate Team rows over time, which defeats the whole point of
keeping team identity permanent in the first place.

Concrete scenario: a club is in the Premier League in the 2023/24
season, gets relegated at the end of it, spends two seasons in the
Championship, and gets promoted back up for 2026/27. If
add_team_to_season simply created a new Team row every time a team was
added to a season, this club would end up with two completely separate
Team rows in the database — one from its original 2023/24 stint, and a
second, unrelated one created when it comes back up in 2026/27. Any
query trying to show "every season this club has been in the Premier
League" would only ever find whichever Team row happens to be linked
to a given SeasonTeam, missing the other stint entirely, even though
it's genuinely the same real club both times.

The name lookup (db.query(models.Team).filter(models.Team.name ==
payload.team_name)) prevents this by reusing the original Team row
whenever the name matches, so every SeasonTeam entry across every
season the club has ever competed in points at the same single Team
row.

WHY THIS WORKS AS AN ANSWER
----------------------------
It connects the lookup directly back to Chapter 2's own design decision
that Team rows are permanent, gives a concrete, dated real-world
scenario (relegation, two Championship seasons, promotion back up)
showing exactly how skipping the lookup would fragment one real club
into two unrelated database rows, and explains the real consequence for
any query trying to trace a club's own full history.