我在很久以前就制作了一个用于处理单位的数据库子模式（好的，我有点夸张；不过大约是20年前）。幸运的是，它只需要处理简单的质量，长度，时间尺寸-
而不是温度，电流或发光度等。游戏的货币方面要简单得多-
在一种货币之间进行转换有多种不同的方法。另一个取决于转换率有效的日期，货币和期限。这是与物理单元分开处理的。
从根本上讲，我创建了一个带有“ id”列，单位名称，缩写和一组尺寸指数的表格“
measures”，每个尺寸指数代表质量，长度，时间。这填充了诸如“体积”（长度= 3，质量= 0，时间= 0），“密度”（长度= 3，质量= -1，时间=
0）之类的名称。
还有第二个单位表，它确定一个度量，然后确定一个特定度量使用的实际单位。例如，有桶，立方米和各种其他相关单位。
第三个表格定义了特定单位之间的转换系数。它由两个单位和将单位1转换为单位2的乘性转换因子组成。这里最大的问题是转换因子的动态范围。如果从U1到U2的转换是1.234E
+ 10，则倒数是一个相当小的数字（8.103727714749e-11）。
S.Lott关于温度的评论很有趣-我们不必处理这些问题。存储过程将解决这个问题-尽管将一个存储过程集成到系统中可能很棘手。
我所描述的方案允许对大多数转换进行一次描述（包括假设单位，例如每两周的弗隆，或者更少的假设但同样晦涩难懂的单位-
在美国以外，例如英亩英尺），并且转换可以得到验证（例如，转换因子表中的单位必须具有相同的度量）。它可以扩展为处理大多数其他单位-
尽管诸如角度（或立体角）之类的无量纲单位存在一些有趣的问题。有支持的代码可以处理任意转换-
或在不支持转换的情况下生成错误。使用该系统的原因之一是，各个国际关联公司会在其本地方便的单位中报告其数据，
