• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 649
  • Last Modified:

Unit conversion table design in database

I am new dabase guy  and recently I got a small project in charge of a databse designing. The table in the excel would be
Item #     Unit    Price
11111      EA     5
11111      DZ     60

Actually 11111 is the same item but with different unit. In my database, I could put two surrogate key to treat them as different items. However, if I update one item price , it would automatically change the one with different unit.

1. Is it necessary to create two tables to distinguish this ? and how could I do that?
2.I know query could handle if we know the relation between EA and DZ, but if the relation between EA and BX is not stable (eg, one box might have 6 or 5 or 4 items ), the query would be really hard to be generalized for thousands items.

Thanks all of you guys.
1 Solution
what I can suggest is to create one table for unit and it's every possible conversion unit with conversion factor, which will help you for sure. for eg:

Unit        ToUnit        conversion
EA          DZ              12
DZ         EA                5
Bill BachPresidentCommented:
I would recommend NOT linking the data together.  There may be reasons why you'd want to do either, so let's review some scenarios.

1) In your example above, the ratio between EA and DZ is 1:12, and the ratio between the pricing is 1:12 as well.  This makes sense.  If this is ALWAYS the case, then you should create the following structure:
Item Table: Item/UnitPrice (11111, 5)
Container Table: Item/Container/QtyPerContainer (11111, DZ, 12)
This will allow you to easily maintain a SINGLE price, and easily extend to multiple containers, as in (11111, BX, 7), (11111, GROSS, 144), etc.

2) However, in many environments, the pricing will vary based on buying in bulk.  If you expect this to ever be the case, then you can do this one of two ways:
2a) Extend the Container Table to include a discount percentage, for which 0 means no discount, 0.10 is a 10% discount, and so on.
2b) Change this schema to be a single table Item/Unit/QtyEaPerUnit/PricePerUnit.

The option 2A will allow you to easily manage pricing, assuming that you can express the pricing change in terms of a percentage.  However, this may be very difficult for evaluating the inventory quantities and for valuation of inventory, since any valuation will always assume that the items are worth full price, even if you sell in a box at a discount.  Option 2B is a bit more flexible for setting EXACT pricing, and you can better evaluate your inventory valuation by breaking it down into boxes, dozens, etc., at their expected resale value.  However, you then need a conversion function to split a box -- i.e. if you run out of individual items and someone needs to open a new box, then you need a function to reduce the DZ pack on-hand quantity by 1 and increase the EA on-hand quantity by 12.  

Neither solution is truely "better" in any sense of the word.  With all databases, though, your decisions made at database design time will directly impact the flexibility of the system and the ease of coding any application to use the data.  Make a "bad" choice, and coding will be difficult; make a "good" choice, and it'll be easy.  The trick of the DBA is to determine the true nature of the business rules and logic that are to run behind the data, and then implement the "best" data schema for the task at hand.  If the business need changes in the future, then a database redesign may also be needed, or coding again gets more difficult.
oiyzhxAuthor Commented:
Thanks i got it ~~~
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now