CODEWITHSUNDEEP
sql-serverdatabase-design
user1162766
user1162766

Reputation:

Database design for retail sales

I’m developing a complete solution for certain business. I have a specific requirement: The system must be able to register sales of products by pieces, let me explain it: If one box of cigarettes contains 20 pieces, the software must be able to register a sale for the entire box or for two cigarettes.

But since the software must also be able to manage the inventory I’m kind of confused as how to design a database to support this feature.

Here’s what a dummy example, I generated it a few seconds ago so I know it’s horrible, I just wanted to show a simple example.

dummy model

I’m planning to add one record on ProductInventory for each available product in the whole store, whenever my client wants to sell some pieces of a certain product the software will: Filter products by barcode, order them by PiecesLeft ascending and subtract the pieces from the top product on the resultset.

Is this the correct way to do it? I’m uneasy about this approach since I think it would generate too many records on ProductInventory, what do you guys think? How would you do it?

I was thinking to merge products with identical barcode and PiecesLeft to have less records but I’m not sure how to do it (Perhaps using triggers?)

So, to summarize, what I want is any advice you can give me and opinions about my approach.

Thank you for your time.

Upvotes: 1

Views: 2916

Answers (3)

Mike Sherrill 'Cat Recall'
Mike Sherrill 'Cat Recall'

Reputation: 95682

When you're thinking of inventory, the problem is that the inventory you store isn't necessarily the inventory you sell. So I think the right way to do this requires a business process that accurately transforms one "kind" of inventory into another.

Let's say you start with 100 cartons of cigarettes in your stored inventory. Somebody comes in and wants two cigarettes. For accurate inventory, the transformations have to look like this.

First transformation
100 cartons -> 99 cartons
               10 packs

Second transformation
99 cartons
10 packs ->     9 packs
               20 cigarettes

Finally, the sale is for just two cigarettes, so your end-of-transaction inventory looks like this.

99 cartons
 9 packs
18 cigarettes

It's not particularly hard to handle that on the database side. In addition to a plain old inventory schema, you'd need some tables that describe the valid transformations--you can't transform packs of cigarettes into bottles of beer--and you'd need stored procedures or application code to do the transformations.

Handling the bar codes is highly application-dependent. In a local nursery (where you buy plants and seedlings), bar code labels often fall off or get lost. The cashiers have a notebook that contains all the bar codes. When a plant is missing a bar code, they scan the barcode that's in the book.

Upvotes: 1

JodyT
JodyT

Reputation: 4412

You say you are developing a complete solution so I assume you are also storing the sales in the database.

In your Product table you could keep track what the number of pieces for that product are. In your OrderRow (or whatever you would be calling it) you then keep track of how many pieces are sold.

To optimize this and decrease the need for joins you could for example add a computed persisted column to Product that holds the total number of pieces - the number of sold pieces.

That is all I can think of with your limited information.

Upvotes: 0

a1ex07
a1ex07

Reputation: 37382

First of all, I'd recommend to get rid of natural PK (barcode). It can be (and probably should be) a unique constraint on barcode field, but not a PK.

About your cigarettes example - I'd say the box is a product itself as far as your application concerns (it might be implemented as a self-relationship in product table or as a separate entity - say selable_product which has it's own price -I'd expect block to be a bit cheaper than 10 packs )

Upvotes: 0

Related Questions