J'ai produit un sous-schéma de base de données pour les unités de manutention il y a une éternité (d'accord, j'exagère légèrement; c'était il y a environ 20 ans, cependant). Heureusement, il ne devait traiter que de simples dimensions de masse, de longueur, de temps - pas de température, ni de courant électrique, ni de luminosité, etc. Le côté monétaire du jeu était plutôt moins simple - il y avait une myriade de façons différentes de convertir entre une devise et un autre en fonction de la date, de la devise et de la période pendant laquelle le taux de conversion était valide. Cela a été géré séparément des unités physiques.
Fondamentalement, j'ai créé un tableau 'mesures' avec une colonne 'id', un nom pour l'unité, une abréviation et un ensemble d'exposants de dimension - un pour la masse, la longueur et le temps. Ceci est rempli avec des noms tels que 'volume' (longueur =3, masse =0, temps =0), 'densité' (longueur =3, masse =-1, temps =0) - et similaires.
Il y avait un deuxième tableau d'unités, qui identifiait une mesure, puis les unités réelles utilisées par une mesure particulière. Par exemple, il y avait des barils, des mètres cubes et toutes sortes d'autres unités pertinentes.
Il y avait un troisième tableau qui définissait les facteurs de conversion entre des unités spécifiques. Il s'agissait de deux unités et du facteur de conversion multiplicatif qui convertissait l'unité 1 en unité 2. Le plus gros problème ici était la plage dynamique des facteurs de conversion. Si la conversion de U1 à U2 est 1.234E+10, alors l'inverse est un nombre plutôt petit (8.103727714749e-11).
Le commentaire de S.Lott sur les températures est intéressant - nous n'avons pas eu à nous en occuper. Une procédure stockée aurait résolu ce problème - même si l'intégration d'une procédure stockée dans le système aurait pu être délicate.
Le schéma que j'ai décrit permettait de décrire la plupart des conversions une seule fois (y compris des unités hypothétiques telles que des stades par quinzaine, ou des unités moins hypothétiques mais tout aussi obscures - en dehors des États-Unis - comme des acre-pieds), et les conversions pouvaient être validées (par exemple, les deux les unités du tableau des facteurs de conversion devaient avoir la même mesure). Il pourrait être étendu pour gérer la plupart des autres unités - bien que les unités sans dimension telles que les angles (ou les angles solides) présentent des problèmes intéressants. Il y avait du code de support qui gérait les conversions arbitraires - ou générait une erreur lorsque la conversion ne pouvait pas être prise en charge. L'une des raisons de ce système était que les diverses sociétés affiliées internationales rapportaient leurs données dans leurs unités locales pratiques, mais le système du siège devait accepter les données d'origine et présenter les données agrégées résultantes dans des unités qui convenaient aux gestionnaires - où différents gestionnaires chacun avaient leur propre idée (en fonction de leur origine nationale et de la durée de leur service au QG) des meilleures unités pour leurs rapports.
