Eu produzi um subesquema de banco de dados para unidades de gestão há uma eternidade (ok, exagero um pouco; foi cerca de 20 anos atrás). Felizmente, ele só tinha que lidar com dimensões simples de massa, comprimento, tempo - não temperatura, corrente elétrica ou luminosidade, etc. Muito menos simples era o lado da moeda do jogo - havia uma infinidade de maneiras diferentes de converter entre uma moeda e outro dependendo da data, moeda e período durante o qual a taxa de conversão foi válida. Isso foi tratado separadamente das unidades físicas.

Fundamentalmente, criei uma tabela 'medidas' com uma coluna 'id', um nome para a unidade, uma abreviação e um conjunto de expoentes de dimensão - um para massa, comprimento e tempo. Isso é preenchido com nomes como 'volume' (comprimento =3, massa =0, tempo =0), 'densidade' (comprimento =3, massa =-1, tempo =0) - e similares.

Havia uma segunda tabela de unidades, que identificava uma medida e depois as unidades reais usadas por uma determinada medida. Por exemplo, havia barris, metros cúbicos e todo tipo de outras unidades de relevância.

Havia uma terceira tabela que definia fatores de conversão entre unidades específicas. Este consistia em duas unidades e o fator de conversão multiplicativo que converteu a unidade 1 em unidade 2. O maior problema aqui era a faixa dinâmica dos fatores de conversão. Se a conversão de U1 para U2 for 1,234E+10, então o inverso é um número bastante pequeno (8,103727714749e-11).

O comentário de S.Lott sobre as temperaturas é interessante - não tivemos que lidar com isso. Um procedimento armazenado teria resolvido isso - embora a integração de um procedimento armazenado no sistema possa ter sido complicada.

O esquema que descrevi permitia que a maioria das conversões fosse descrita uma vez (incluindo unidades hipotéticas como furlongs por quinzena, ou menos hipotéticas, mas igualmente obscuras - fora dos EUA - como acre-feet), e as conversões poderiam ser validadas (por exemplo, ambas unidades na tabela de fatores de conversão tinham que ter a mesma medida). Ele poderia ser estendido para lidar com a maioria das outras unidades - embora as unidades adimensionais como ângulos (ou ângulos sólidos) apresentem alguns problemas interessantes. Havia um código de suporte que lidava com conversões arbitrárias - ou gerava um erro quando a conversão não podia ser suportada. Uma razão para este sistema era que as várias empresas afiliadas internacionais reportariam seus dados em suas unidades localmente convenientes, mas o sistema de HQ tinha que aceitar os dados originais e ainda apresentar os dados agregados resultantes em unidades adequadas aos gerentes - onde gerentes diferentes, cada um tinham sua própria ideia (com base em sua formação nacional e tempo de serviço no QG) sobre as melhores unidades para seus relatórios.