Thank you for that POV, Jamie. The problem is that floating point is only "approximately" equal -- and if you're not careful about it, you can see things like this:

User enters 4.8; we multiply by 18.01559 and round -- we get 86. We store 86. For display back to the user's units, we convert from 86 by dividing by 18.01559 and then round to the nearest single decimal place. We display 4.7. That's bad.

If we store the BG values as integers in mg/dL, this will always happen, no matter how we condition the data, because integers don't have enough resolution. It may be within the resolution of the meter, but it's not what humans expect to see.

If, instead, we store floating point numbers measured in mmol/L, and round displays to one decimal place on display of mmol/L and to integers on mg/dL, we get absolutely correct displays for both types of units for all values of bg from 0 to 4000 mg/dL. (I wrote code to try it.)

We should NOT store numbers as entered as numbers, and the database should not have two different types of readings in it. That way lies madness.

What we should do is store values in floating point units as mmol/L -- if they're entered as mg/dL the values will contain lots of significant digits. We do not drop those.

So if you enter 100 mg/dL, when converted that's stored as 5.55074799105. When you convert it back and round to the nearest int, you get 100 again. If you happen to need to display it in mmol/L, you display it as 5.6.

To summarize -- values must be stored in a single unit as floating point and not truncated or rounded in storage. They are converted to display units using floating point math and then rounded to the appropriate number of decimal digits for display. We should have fields for the text string we were originally given as a number, if any, and for the units we were given. But those are only for provenance purposes; we should never need to interpret them again.