So to count thing you do select count(id) from inventory_items group by warehouse, sku.

Or did I read that completely wrong?

Rhetorical in this conversation, but something for me to consider with the folks at work tomorrow.

On your last point: I actually don’t mind counter caches! I haven’t (yet) gotten bitten by one on an association but that could be a consequence of the small scale I’m operating at. Or, I’ve missed some problems.

I just balk at the rails "auto update some count" thing because how could you ever trust it?

Strictly internal app for managing serialized inventory between various locations out there in the real world and making sure we restock depending on configured conditions, contractual obligations, etc.

So, in this case at least, the reporting aspect (knowing how much inventory is where and when) is part of the core function.

There's also a bunch of knock-on data-related tasks that the team's pulling out from a replica database and using some off-the-shelf dashboard kind of thing. I tend not to have much to do with that, though.

Transactional logic in our case never needed to know the counts. Only reporting and that was not needed realtime.

Much of our complex transactional queries were in SQL-way easier to understand and maintain than Active Record.

Appreciate your feedback on this one.

I’m responsible for an app that’s growing beyond its initial and rudimentary data model. I’m beginning to see a path out of the current problems, but it’ll involve some tricky data migrations in addition to the foundational modeling improvements.

It’s closely related to what I outlined in the problem statement, but isn’t exactly the same. Its utility is more in triggering action when certain conditions are met.

So maybe “StockLevel” for this new join model…?

“should SKU belong to a warehouse?”

I don’t believe so, no. SKU here would be for categorization and reporting, as you noted.

my other tips are to make sure to include timestamp columns, because you will probably want them for some reason or another, and don’t forget your indexes

(also, InventoryAllocation isn’t bad!)

A JSONB column on the Warehouse model also feels less-than-ideal.

A join model between the Warehouse and InventoryItems models is an approach. The counter cache could be on the join model. That'd still involve including/joining the join model when the app wants to display inventory counts along with a Warehouse but would also avoid manually fiddling with counters as InventoryItems move from Warehouse to Warehouse.