Reviewing Your Own Work

Read the schema as someone who has to add a feature to it. Where would a new kind of record go? What would break if one author changed their name? Which column would you have to update in six places?

Those questions find design problems faster than any checklist.

Then read the queries as a skeptic.

Is there an inner join where absence matters?

Is there a SUM after a join that could have multiplied rows?

Is there a filter on a column that contains NULLs?

Is there a LIMIT without an ORDER BY?

Is there a number in the README that no query produces?

That last one is the one somebody else will find.

Why this belongs in your portfolio. A designed, normalized, indexed schema with real data and explained queries is a different kind of artefact from an application. It shows you can model a problem rather than only build a screen, and it is the thing that makes the Full Stack Engineer course, which you are now ready for, make sense from both ends.