Skip to content
All posts

The schema is the product decision

Two years of B2B stock systems taught me that the hardest arguments happen in the table design, not in the interface.

Stock only ever moves one way. Whether the numbers can follow it is decided in the table design.

Stock is the least forgiving thing you can put in a database. A number that is wrong by one is not a rounding error to the warehouse; it is an order that ships short and a customer who stops trusting the panel.

The system I worked on kept its truth in a chain: a movement row was written, a trigger updated the warehouse total, and a second trigger pushed that up into the product. It was elegant right up to the day a bundled product entered the catalogue and the chain had to run the other way too — the components decide the bundle, and the bundle must never decide itself.

You are not choosing column types. You are deciding what your business is allowed to mean.

The fix was not clever code. It was admitting that a bundle is a different kind of thing from a product, saying so in the schema, and then giving the recalculation a session flag so it could not fall into its own loop. Once the model was honest the queries got shorter, not longer.

That is the part I would tell anyone starting on a commerce system. You are not choosing column types. You are deciding what your business is allowed to mean, and every screen built on top inherits that decision whether it likes it or not.

In short

  • A bundle is a different kind of thing from a product. Say so in the schema before you say it in code.
  • Give a recalculation a session flag, or the triggers will eventually find their own loop.
  • An honest model shortens the queries written on top of it. A convenient one lengthens them.

Keep reading

Three more pieces from the same desk, on the parts of the work that are easier to get wrong than to explain.