Exercise 2: The Real Design Reasoning Behind Type Affinity — Possible Solution
====================================================================

THE HISTORICAL/DESIGN REASONING
------------------------------
Per this chapter, "this isn't an accident or an oversight — it's
documented, deliberate design, tracing directly back to sqlite1-1's
own embedding material. SQLite was built as a general-purpose,
embedded storage engine meant to work smoothly from dynamically-typed
scripting languages, where a value of the 'wrong' type shouldn't
necessarily hard-fail an entire operation the way it might need to in
a strict, statically-typed system serving many different,
independently-written applications with different assumptions about
the data."

CONNECTING THIS TO SQLITE1-1'S OWN EMBEDDING MATERIAL
------------------------------
Per sqlite1-1, SQLite is "a C library, linked directly into the
application's own process," built for a SINGLE embedded application
rather than many separate, independently-written networked clients
(which is what MySQL/Postgres serve). Because SQLite is so often
embedded directly into applications written in dynamically-typed
scripting languages (Python, JavaScript, and similar), where a single
variable can casually hold a number, a string, or something else at
different points without any language-level type enforcement, a
strict database-level type system would create constant, low-value
friction between the scripting language's own loose typing and the
database's own rules — friction MySQL/Postgres don't face in the same
way, since they're typically accessed by more deliberately-typed
client code across a network boundary, with type conversion handled
explicitly.

WHY THIS IS A GENUINE TRADE-OFF, NOT SIMPLY A MISTAKE
------------------------------
Per this chapter, "this flexibility is genuinely useful for SQLite's
own actual use cases — loosely-typed application data, rapid
prototyping, embedded contexts where the application itself is the
sole writer and already controls data quality directly. It's also,
honestly, the single most commonly cited source of real bugs for
anyone arriving from a strict-typing background. Both things are true
at once." This is what makes it a genuine trade-off rather than a
flaw: the SAME design choice that produces real, well-documented bugs
for developers expecting MySQL/Postgres-style strictness is ALSO the
exact choice that makes SQLite frictionless to embed directly into
loosely-typed application code, which is precisely the use case
SQLite was built to serve. Calling it "just a mistake" would ignore
the real benefit it provides in SQLite's own actual, intended
context — it's a deliberate choice with both a real cost and a real
benefit, not an oversight with only a cost.

WHY THIS WORKS AS AN ANSWER
------------------------------
It connects the type-affinity design choice back to sqlite1-1's own
embedding material specifically (not just restating "it was designed
this way"), and explains precisely why the chapter frames this as a
genuine trade-off — the same property causes both the real bugs and
the real benefit, rather than being pure downside.