My first instinct is to add a Units column to any table with a measurement. The value in Units would be a foreign key to a Units table. Another table, Conversions, could hold conversion factors.
In addition to what jkl said, I'd like to point out that if you may someday find yourself forced to deal with many units you'll have to make the unit column homogenous. Easy example is mixing cm/s, km/h and miles/day.
In one of my SQLite DB I have to deal with almost all SI units and a few more exotic, plus input and output values with prefies (kilo, deci, micro, ...). To maintain consistency I express every value in SI units and store the unit in dimensional form in its own column. I had to add dimensionless non-units like radian and steradian, which are now disregarded by the SI system but are needed to maintain semantic consistency.
So for instance I convert pressure inputs expressed in Pa, mmHg or bar to their equivalent SI value in kg m^-1 s^-2 and store the values along dimensional unit in L^-1 M T^-2. Now I can safely proceed to any needed computation without worrying to avoid mixing apples and chairs, then convert the result into expected practical unit, say megapounds per barn.
Of course your use case may not require that much precaution. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
