4

In my application users compute some engineering data (physical quantities like lengths, and weights).

Currently the core formulas work on and assume English system, but user can select English or Metric system to work in. If English is selected, no special provisions are required, everything is done in English.

But if user selects Metric, there are two conversions that take place -- one on input and on on output, to keep things consistent. Currently the existing application I work with, stores data in both units.

My question is about which values do I store in the database -- the ones that are using English units or the converted ones that are using Metric?

More so, is this a type of question where the answer is "toss a coin", or are there some definitive benefits of one over the other?

More Detail on what can happen when user chooses to use Metric

After initial conversions the computation engine crunches the English unit system numbers, and is ready to save them in the database, here are my two choices:

Way 1 - Storing Metric Data in database (also storing English Data as well)

  1. Convert to data to Metric system, when needed, and store it in the database (making note that data is in Metric units). With English data, store it as is in the database and mark it as English
  2. When viewing data, no conversion required

Way 2 - Storing English Data in database (and only English)

  1. Do NOT convert, store data using English system (but making note that data is in English units)
  2. When viewing data, convert to Metric for display, when user-requested.
  • 1
    I thought I saw this question before, turns out I was thinking of another one of your questions and it appears not to be a duplicate: Strategy to use two different measurement systems in software. This other question from our resident engineer might be useful as well: Data structure for accessing units of measure. – user22815 Feb 10 '17 at 21:29
  • True ... the other of my question dealt more with finding a process which was hindered in part by tightly coupled "values" and "value presentation". A concept of Unit of Measure was introduced (which coincides with Way 1). Jon Raynor's answer presents the other opportunity (Way 2), which is just as viable ... And here I"m debating which way is "better" but so far both are "acceptable" – Dennis Feb 10 '17 at 21:51
6

Another possibility:

Store the unit of measurement preference on a user table as opposed to the measurement value table.

Store all measure data in a consistent form (Either English or Metric). Do the conversion as needed based on user preference.

Also, if one needed to export the data it would be easier to work with if all values in a consistent format.

  • It is important to show a consistent user interface, this is the reason I support that the input and output system should be a user preference. – Jonathan Rosenne Feb 10 '17 at 22:20
  • How do you mean? Because user interface can exist on its own (and be consistent in that sense) regardless of how data is stored internally. User preference can also be stored regardless of internal representation of data. – Dennis Feb 10 '17 at 22:23
  • 1
    @Dennis I think Jon touches a key subject here, if you need to make some statistics from your data, and find what the medium of data X is, when all your data is consistent you just run a query and you're done. If you need to make conversions, the things get a little harder – fernando.reyes Feb 10 '17 at 22:40
  • 1
    You should also do all internal calculations using the same units you use in the database. The conversion should only happen in the UI layer. Treat it just like localization. – mrog May 3 '17 at 21:11
4

You could also store the measurement system with the value, so you know EXACTLY what it is. Could look like this:

id    | value     | system-of-measurement | unit-of-measure
------+-----------+-----------------------+-----------------
1     | 11.3      | METRIC                | metre
2     | 0.653     | IMPERIAL              | quart

You could then have views on top of this table which perform calculations on the data for you so that when you select from the views, everything is consistent, but you still store it exactly as the user entered it and no one will get confused when they look at your code in the future and try to guess how it's stored.

  • Thanks. It is essentially the Way #1 - do conversion, store Metric data with Metric flag – Dennis Feb 10 '17 at 20:17
  • @Dennis: Ah, ok. I didn't realize you were also planning to store information on what measurement system the incoming data was entered in. I'd still consider using views to do the conversion if it's possible. – FrustratedWithFormsDesigner Feb 10 '17 at 20:20
  • Well, yes ... I think you are doing the same in your answer -- storing which measurement system was being entered... in system-of-measurement column. I mean I can also see your answer removed from my situation to where you have a simple rule that value must match system-of-measurement column. I think it is simpler this way than my "Way 2" where I store English units along with Metric flag, and units are not matched to the system of measurement flag – Dennis Feb 10 '17 at 20:30
  • 1
    Instead of system of measurement, you should probably specify the actual units of measurement. Knowing that 11.3 is metric does not tell me whether we are using grams, kilograms, or milligrams. Also, I would recommend sticking to one system internally. If you end up switching between systems multiple times for the same data, you could end up with some loss of precision due to rounding each time the data is converted. Eventually you end up with a bizarre value (Admittedly this could be a edge case that never really happens). – David Cram Feb 10 '17 at 21:10
  • 1
    This, or some form of it, is the best idea. If you always store it in one unit, you have to convert some to store it, and then convert back to get the original value, and sometimes you can't go exactly there and back (think a ratio of 1/3 for instance). Store what the user entered and what units they entered it in, and compute from there. – Scott Whitlock Feb 14 '17 at 17:29
0

How precise can your storage be? Would you store in a fixed point, floating point, or some other aggregate type? Imperial measurements aren't just fractional. They are fractions with common values for denominators. These denominators are usually powers of two (1/2, 1/4, 1/8, etc). You could store an imperial measurement as two integers with one of them being a short. The short would be the denominator, the other would be a multiplier/numerator. So a database record would have those two fields, plus a unit like "cups" or "miles." If your input will likely only be imperial, you may be able to save some space over storing the measurement as a single field with a larger decimal type like a double.

  • since computations are done I end up with something like 4.123 inches. Not all values are fractional to where I can store them as fractions. I just store them as doubles. – Dennis Feb 13 '17 at 5:29
0

You can try;

https://github.com/gnapse/metric

And can keep values as English text.

Update: Another library:

github.com/lahma/PhysicalMeasure

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.