UOM (units of measure) design patterns

Question

Looking for general design patterns principles with respect to storing and converting known values (i.e. meters to feet). Been googling with no luck so I must be missing something.

Assuming many fields with various UOM in a single table what is the best practice? Currently many of the fields are implied and we are looking at standardizing this. We want to give users freedom to enter in their UOM but others to view in their preferred UOM.

Should I store 'entered value' and convert to some common primitive (user enters feet I convert to meters and store that)? Should I store this entered feet value as audit backup?

I am not the only consumer of some database table, is it better that other applications always do the conversions knowing value+UOM vs raw user entered value.

Are there serious conversion implications for precision that I might be missing. Meters>feet>meters should be reliable enough of a conversion for line of business app (conversions can be to 17th decimal place but displayed and entered values are limited to 2-4 decimal places)

Any other thoughts or links to point me in right direction so I'm not reinventing a solution to a known problem?

Note that I'm not envisioning some grand solution with operator overloading but more what will work in practical application that average Joe Developer can maintain.

Answer 1

If you want a pattern that follows UOM, JSR-275 (java) addresses that. A popular library that implements JSR-275 is JScience.

As for storing of the values, I would just create a column for value and measurement type (e.g. metre/feet, etc.) that is never changed. Conversion can then be easily done on request.

Answer 2

Look at the book Analysis Patterns. Also, look at the Quantity pattern.