Personal Catalogue: PHP & MySQL — Chapter 2, Exercise 2
====================================================

TASK
Explain, in your own words, why a shared items table with a generic
creator column was chosen over four separate per-type tables, and
name the one real feature that decision makes simpler.

SOLUTION

A fully normalized design would give each item type its own table with
exactly the right columns for that type — a books table with an author
column, a music_cds table with an artist column, a dvds table with a
director column, and so on. Every column on every row would genuinely
apply to that row, which is the "textbook correct" way to model data
that's this different in shape.

The catalogue app was built with a shared items table instead, where a
single generic creator column stands in for author, artist, or
director depending on the row's own item_type_id. This means some
columns are meaningless for some rows — a DVD's own author column is
always NULL, for example — which is a real, deliberate cost of this
design.

The feature this decision makes dramatically simpler is search across
the whole collection — the "do I already own this?" feature. With one
shared items table, finding every item (of any type) whose title
matches a search term is a single SELECT with a WHERE clause. With
four separate tables, the same search would need a four-way UNION
query, joined and re-run every time the search box is used, and every
time a new item type might be added later.

Since the whole point of this project is quickly checking "do I
already own this book/CD/DVD?", keeping that specific query as simple
as possible was judged more valuable than having a "purer" schema with
no NULL columns anywhere.

WHY THIS WORKS AS AN ANSWER
----------------------------
It names the real trade-off (some meaningless NULL columns) honestly
rather than pretending the shared-table design is free, and ties the
decision to the one concrete feature (cross-type search) the chapter
itself gave as the reason, rather than a vague "it's simpler."