Question

I am developing a web application that will allow people to keep track of products that they will move around.

Example:
I have 10 cups in my warehouse. I move 5 cups to ShopA and 5 cups to ShopB. I then move 3 cups from ShopA back to my warehouse.

In terms of my db structure, i thought of having a products table that looked something like this:
product_id
location_id
quantity

But it seems a little clumsy. In the example i would have 1 record in products table for this product, then 2, then 3.

My question is:
Is it better in this case to have 10 rows (1 row per item instead of a quantity field) for this product and change location of each product? But if this table stores the products for lots of users, in a very short period of time, the table will have millions of rows… should i be worried about that?

I am very interested in what is considered the best practice in this kind of situation.

thank you!

Answer 1

I agree with Ollie Jones’ answer, but I would like to add that the “Double Entry Bookkeeping” method would be to have rows like this:

CREATE TABLE [Transactions] (
    [FromLocationId] /* foreign key to the locations */,
    [ToLocationId] /* ditto */,
    [Amount]
)

This way, there is only one row per transaction.