Exercise 1: Strict Static Typing vs. Type Affinity, Demonstrated — Possible Solution
====================================================================

MYSQL/POSTGRES'S STRICT STATIC TYPING
------------------------------
Per this chapter, "MySQL and Postgres both use static, strict column
typing — a column declared INTEGER can only ever store integer
values (or NULL); inserting 'hello' into it raises a real, hard error
at insert time." The column's declared type is an enforced rule: any
value that doesn't genuinely match is rejected immediately, and the
INSERT itself fails.

SQLITE'S OWN TYPE AFFINITY
------------------------------
Per this chapter, "SQLite works differently: it's dynamically typed
at the value level, not the column level. A column's declared type is
really just a hint — a type affinity — that SQLite uses to decide how
to try to convert an incoming value, but it does not reject a value
just because it doesn't match." The declared type is closer to a
suggestion for CONVERSION than a hard rule for VALIDATION — SQLite
attempts to coerce the incoming value toward the column's affinity,
but if that coercion genuinely can't succeed, it stores the value
as-is instead of refusing it.

THE CHAPTER'S OWN CONCRETE EXAMPLE
------------------------------
Per this chapter:

  CREATE TABLE example (id INTEGER, quantity INTEGER);
  INSERT INTO example VALUES (1, 'five');
  SELECT * FROM example;
  -- 1 | five

Even though the quantity column is declared INTEGER, and 'five' is
plainly not a number, this INSERT succeeds in SQLite by default — the
text value 'five' simply couldn't be coerced into a number, so SQLite
stored it exactly as given, as TEXT, rather than rejecting the insert.
Per this chapter, "the identical statement against a MySQL table in
strict mode, or against a Postgres table, would fail immediately" —
both of those engines would refuse the INSERT the moment they saw a
non-numeric value headed for an INTEGER column.

THE CORE DIFFERENCE
------------------------------
MySQL/Postgres enforce type correctness AT THE COLUMN, rejecting
anything that doesn't match. SQLite (by default) only ATTEMPTS
conversion, and falls back to storing the raw value if that attempt
fails, meaning the column's declared type never actually guarantees
what kind of value will end up stored there.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states both models precisely using the chapter's own wording, and
walks through the chapter's own worked example step by step to show
concretely what happens differently in each system, rather than
describing the difference only in the abstract.