Inventory database design [closed]

Answer 1

It's important to consider the existing system and the cost and risk of changing it. I work with a database that stores inventory kind of like yours does, but it includes audit cycles and stores adjustments just like receipts. It seems to work well, but everyone involved is well trained, and the warehouse staff aren't exactly quick to learn new procedures.

In your case, if you're looking for a little more tracking without changing the whole db structure then I'd suggest adding a tracking table (kind of like from your 'transaction' solution) and then log changes to the inventory level. It shouldn't be too hard to update most changes to the inventory level so that they also leave a transaction record. You could also add a periodic task to backup the inventory level to the transaction table every couple hours or so so that even if you miss a transaction you can discover when the change happened or roll back to a previous state.

If you want to see how a large application does it take a look at SugarCRM, they have and inventory management module though I'm not sure how it stores the data.

Answer 2

• The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises
• The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries
• The Data Model Resource Book: Universal Patterns for Data Modeling

I have Vol 1 and Vol 2 and these have been pretty helpful in the past.

Answer 3

both are valid, depending on the circumstances. The former is best when the following conditions hold:

• the number of items to sum is relatively small
• there are few or no exceptional cases to consider (returns, adjustments, et al)
• the inventory item quantity is not needed very often

on the other hand, if you have a large number of items, several exceptional cases, and frequent access, it will be more efficient to maintain the item quantity

also note that if your system has discrepancies then it has bugs which should be tracked down and eliminated

i have done systems both ways, and both ways can work just fine - as long as you don't ignore the bugs!

Answer 4

We solve different problems, but our approach to some of them might be interesting to you.

We allow the system to make a "best guess", and give the users regular feedback about any of those guesses that look wrong.

To apply this to inventory, you could have 3 fields:

inventory_received
inventory_sold
estimated_on_hand

Then, you could run a process (daily?) along the lines of:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Of course, this relies on users looking at this alert, and doing something about it.

Also, you could have a function to reset inventory some how, either by updating inventory_sold/received, or perhaps adding another field "inventory_adjustment", which could be positive or negative.

... just some thoughts. Hope it's helpful.

Answer 5

I can see some benefit to having the two columns, but I'm not following the part about discrepancies - you seem to be implying that having the two columns (in and out) is less prone to discrepancy than a single column (current). Why is that?

Answer 6

I think this is actually a general best-practices question about doing a (relatively) expensive count every time you need a total vs. doing that count every time something changes, then storing the count in a field and reading that field whenever you need a total.

If I couldn't use transactions, I would go with the live count every time I needed a total. If transactions are available, it would be safe to perform the inventory update operations and the saving of the re-counted total within the same transaction, which would ensure the accuracy of the count (although I'm not sure this would work with multiple users hitting the database).

But if performance is not really a huge problem (and modern databases are good enough at counting rows that I would rarely even worry about this) I'd just stick with the live count each time.