Inventory Management Table Structure

Question

Our team needs to track inventory for essentially an in-house created ERP system. We will need to frequently access the amount of inventory in the system for a given item at a given warehouse and have the ability to track what changed the inventory and when.

The initial thought was to just have the adjustments table and calculate the current inventory each time we looked at it. Through our testing it became clear that making this calculation was too costly given how many times we would be doing it each day.

Our new idea is to have an adjustments table with the history, but also keep a table with what the current inventory is. When an adjustment is made, our program will update both the adjustments table and the current inventory tables at the same time. I don't really like this solution since it requires 2 updates to make one change. What if one fails? How do you reconcile when the adjustments don't reflect what's in the inventory table?

Does anyone have a better approach?

Answer 1

If you can't do all the necessary updates in a single transaction, you'll need an administrative procedure (as opposed to a declarative constraint) to make sure the data is right. For example, you can run a cron job that tests the totals against the details. How often you do that depends on how long the cron job takes to run, and how long a cron job your application can tolerate.

I'd prefer a trigger on the detail table plus a periodic cron job. Let the trigger adjust the total for each transaction. The cron job makes sure no updates were missed. (Most dbms will let you disable triggers for maintenance; the cron job will remind you when you've inevitably forgotten to enable them again.)