Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


Unit conversion table design in database

Posted on 2009-07-02
Medium Priority
Last Modified: 2012-05-07
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.
Question by:oiyzhx
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 31

Expert Comment

ID: 24770485
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
LVL 28

Accepted Solution

Bill Bach earned 200 total points
ID: 24773356
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.

Author Closing Comment

ID: 31599371
Thanks i got it ~~~

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

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

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Your data is at risk. Probably more today that at any other time in history. There are simply more people with more access to the Web with bad intentions.
In this article, we’ll look at how to deploy ProxySQL.
This is a high-level webinar that covers the history of enterprise open source database use. It addresses both the advantages companies see in using open source database technologies, as well as the fears and reservations they might have. In this…
In this video, Percona Solution Engineer Dimitri Vanoverbeke discusses why you want to use at least three nodes in a database cluster. To discuss how Percona Consulting can help with your design and architecture needs for your database and infras…
Suggested Courses

604 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question