Produje un subesquema de base de datos para unidades de manejo hace un eón (está bien, exagero un poco; sin embargo, fue hace unos 20 años). Afortunadamente, solo tenía que lidiar con dimensiones simples de masa, longitud y tiempo, no con la temperatura, la corriente eléctrica, la luminosidad, etc. Algo menos simple era el lado de la moneda del juego:había una miríada de formas diferentes de convertir entre una moneda y otra según la fecha, la moneda y el período de validez de la tasa de conversión. Eso se manejó por separado de las unidades físicas.
Fundamentalmente, creé una tabla de 'medidas' con una columna 'id', un nombre para la unidad, una abreviatura y un conjunto de exponentes de dimensión, uno para masa, longitud y tiempo. Esto se completa con nombres como 'volumen' (longitud =3, masa =0, tiempo =0), 'densidad' (longitud =3, masa =-1, tiempo =0), y similares.
Había una segunda tabla de unidades, que identificaba una medida y luego las unidades reales utilizadas por una medida en particular. Por ejemplo, había barriles, metros cúbicos y todo tipo de otras unidades de relevancia.
Había una tercera tabla que definía los factores de conversión entre unidades específicas. Este consistía en dos unidades y el factor de conversión multiplicativo que convertía la unidad 1 en la unidad 2. El mayor problema aquí era el rango dinámico de los factores de conversión. Si la conversión de U1 a U2 es 1,234E+10, entonces el inverso es un número bastante pequeño (8,103727714749e-11).
El comentario de S. Lott sobre las temperaturas es interesante:no tuvimos que lidiar con eso. Un procedimiento almacenado habría solucionado eso, aunque la integración de un procedimiento almacenado en el sistema podría haber sido complicada.
El esquema que describí permitía que la mayoría de las conversiones se describieran una vez (incluidas unidades hipotéticas como estadios por quincena, o menos hipotéticas pero igualmente oscuras, fuera de los EE. UU., como acre-pies), y las conversiones podían validarse (por ejemplo, tanto unidades en la tabla de factores de conversión tenían que tener la misma medida). Podría extenderse para manejar la mayoría de las otras unidades, aunque las unidades adimensionales como los ángulos (o ángulos sólidos) presentan algunos problemas interesantes. Había un código de soporte que manejaría conversiones arbitrarias o generaría un error cuando la conversión no pudiera ser soportada. Una de las razones de este sistema era que las diversas compañías afiliadas internacionales reportarían sus datos en sus unidades locales convenientes, pero el sistema de la sede central tenía que aceptar los datos originales y, sin embargo, presentar los datos agregados resultantes en unidades que convenían a los gerentes, donde diferentes gerentes cada uno tenían su propia idea (basada en sus antecedentes nacionales y la duración del servicio en el cuartel general) sobre las mejores unidades para sus informes.
