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.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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 BachPresident and Btrieve GuruCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
oiyzhxAuthor Commented:
Thanks i got it ~~~
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.