u/Previous_Version5651

The "refactor the terrible query" track is the right instinct. One drill that helped me more than any course: take one messy query and rebuild it as a chain of CTEs, each CTE owning exactly one business rule, and after each step run a count(*) plus one known total to prove the row count and the money still match. You end up with a query a reviewer can audit line by line, and you learn where the original silently dropped rows (usually a LEFT JOIN that became an INNER JOIN in WHERE). Doing that on someone else's bad query is better practice than writing greenfield SQL, because greenfield never teaches you to read code you did not write.

Nice 鈥?the insert-order pain is the real lesson here. Two habits that saved me when I built a similar schema:

1. Insert parents first, then children, and wrap the whole seed in one transaction so a failed child insert rolls back instead of leaving a half-populated library.

2. When an insert fails on a foreign key, query the parent table for the exact id before assuming the child row is wrong. Most of the time the parent row was never inserted, or the id type differs (INT vs BIGINT, case-sensitive codes).

The data dictionary in the README is a good next step 鈥?it makes the "which table owns this id" question obvious when you start writing joins.