Exercise 3: Ordinary Tables, Postgres1-3's Warning, and the Whole-Schema Lesson — Possible Solution
====================================================================

WHY CUSTOMERS/ORDERS/ORDER_ITEMS NEEDED NOTHING POSTGRES-SPECIFIC
------------------------------
Per this chapter's own tip-box, "three tables in this schema
(customers, orders, order_items) needed nothing Postgres-specific at
all — exactly as expected, since postgres1-1 opened this course by
promising it wouldn't re-teach SQL fundamentals mysql2/mysql3 already
cover." Looking at the actual schema, these three tables use only
ordinary column types (SERIAL, TEXT, INT, NUMERIC, TIMESTAMPTZ),
ordinary foreign key references, and no arrays, ranges, JSONB, or any
other Postgres-distinguishing type. Their data genuinely IS
straightforwardly relational — a customer has a name and email, an
order belongs to a customer, an order item belongs to an order and a
product, with fixed quantity/price fields. There was no genuine design
problem here that fixed relational columns don't already solve
cleanly, so none of this course's own richer features were reached
for.

WHY THIS DEMONSTRATES POSTGRES1-3'S OWN WARNING AT THE WHOLE-SCHEMA
LEVEL
------------------------------
Per postgres1-3's own warn-box, "richness is a capability, not an
obligation... a rich type system expands what's available; it doesn't
change when normalization is still the right call." postgres1-3 made
this point about individual COLUMN design decisions (don't reach for
an array or a custom enum type just because it's available, when a
proper join table would serve the data better). This capstone
demonstrates the exact same discipline, but scaled up to the level of
an entire SCHEMA: rather than forcing every table to showcase a
Postgres-specific feature for its own sake, only categories (which
genuinely needed hierarchical structure) and products (which
genuinely needed variable, per-category attributes) reached for this
course's own distinguishing capabilities — JSONB and recursive CTEs
respectively. customers, orders, and order_items were left as
ordinary relational tables precisely because that's genuinely the
right design for the data they hold, not because Postgres-specific
features weren't available to use there too.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains concretely why the three named tables have no genuine need
for Postgres-specific features, and explicitly connects this design
choice to postgres1-3's own column-level warning, showing how the same
underlying discipline (use richness only where it's actually earned)
applies at the scale of an entire schema's own table-by-table design.