Premier League Predictor: Django & MySQL — Chapter 1, Exercise 2
====================================================

TASK
Explain why utf8mb4 is the correct charset choice for the pl_predictor
database instead of plain utf8, and why the OPTIONS charset setting in
DATABASES needs to match it.

SOLUTION

MySQL's own historically-named "utf8" charset is not actually a full
implementation of UTF-8 — it's a restricted, 3-byte-maximum encoding
left over from an early MySQL design decision, genuinely incapable of
storing characters that require 4 bytes in real UTF-8, which includes
a large range of real Unicode characters such as emoji and some less
common CJK characters. "utf8mb4" ("UTF-8, most bytes 4") is MySQL's own
real, later-added full implementation of UTF-8, capable of storing the
complete Unicode range the original "utf8" charset silently can't. For
any new MySQL database created today, "utf8mb4" is the genuinely
correct choice specifically because it doesn't have that hidden gap.

The OPTIONS charset setting in Django's DATABASES configuration
controls what charset Django's own connection to MySQL actually uses
when sending and receiving data — it's a separate setting from the
charset the database itself was created with. If the database is
created with utf8mb4 but Django's own connection defaults to plain
utf8 instead, the mismatch becomes a real, silent problem: data that
requires the full utf8mb4 range could be truncated, corrupted, or
rejected by the connection layer before it ever reaches the database's
own storage engine, even though the database itself is fully capable of
storing it correctly. Setting 'charset': 'utf8mb4' inside OPTIONS keeps
the connection's own behavior consistent with what the database was
actually created to support.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains the real, specific technical limitation of MySQL's own
"utf8" charset (a restricted 3-byte encoding, not true UTF-8), states
why utf8mb4 is the genuinely correct modern choice, and separately
explains why the connection-level OPTIONS setting is a distinct
concern from the database's own charset — one that has to be
explicitly matched, not assumed automatic.