Member-only story
The Schema Three Chapters Were Already Relying On (Chapter 14)
Chapter 12 spent several pages arguing that the only guard against assigning the same product to the same category twice is a unique constraint on (category_id, product_id). It rejected a pessimistic read lock on the grounds that a lock delays a conflicting change rather than preventing it, settled on reading current state to classify a batch, and said plainly that the database is the only real arbiter of the race that remains.
That constraint did not exist. Neither did the foreign key with ON DELETE CASCADE that the same chapter called a backstop, nor the BINARY(16) column that the version 7 UUID decision quietly depends on. Three chapters of reasoning had been written against a schema that was still a sentence in a paragraph, and the previous chapter configured Flyway to apply migrations without there being a migration to apply.
Writing it is where several earlier decisions stop being arguments and become something a database will enforce or refuse. A few of them also turn out to have been wrong, or at least incomplete, in ways only visible once the columns have types.
One file, or one per table
Before any of that configuration does anything, there has to be something in classpath:db/migrations, and there are two questions before the SQL…
