单位和复杂单位转换的良好关系结构是什么？

我的公司从事能源行业，我需要想出一种很好的方法来表示计量单位的转换。我已经进行了一些搜索，但还没有找到需要的深度方面的好文章。大多数有关单位转换的信息都假定给定的单位1有一个已知的（硬编码）转换率可以到达单位2，并且它是简单的数学运算（这是我发现的最复杂的示例，仍然没有用）。但是，在现实世界中并非总是如此，对于我们必须处理的事情当然也不是正确的。（很抱歉写了很长时间-我正尝试提供尽可能多的信息！）

棘手的示例1： 某些转换会随时间而变化，例如将$ 5转换为Euros，反之亦然。听起来这与能源无关，但实际上在能源商品市场（想想股票市场）中。

棘手的例子2 ：（过于 简单化）某些天然气燃烧得比另一些更热。另外，可以根据气体中的能量（例如Therms）或基于该气体的体积（例如1000立方英尺的MCF）来测量/存储天然气，还有其他可能性（例如作为吨用于质谱）。汽油的一个例子是1加仑的93辛烷无铅汽油比1加仑的93辛烷无铅汽油少。

棘手的示例3： 除了拥有这些度量单位之外，我们还经常需要处理费率，例如$ / Therm或$ / MCF。因此，我们需要某种方式来处理这些费率以及它们与基本单位的关系，因此，如果我们需要从$ / Therm转换为€/ MCF，我们可以并且它使用与从Therm转换为MCF相同的发布费率。

棘手的示例4： 以前，我曾经非常宽松地使用“ 能量 ”一词，有时可能会错误地使用它。从现在开始，这种情况正在改变。所以最后一个曲线球是我们既要处理能源又要处理电源。对于电力，这意味着kWH与kW（尽管是Yahoo Answers，这是一个相当不错的解释）。数据比喻：这就像将下载的总MB数据与Mbps进行比较ISP为您提供的带宽。像数据一样，能量也需要时间来传递。继续进行数据类比，我们可能必须计算一段时间内消耗的平均有效带宽，因此，假设在1分钟内下载了60MB，则“有效”速率将为60 * 8/60 = 8Mbps。这里的“窍门”是，如果我们将Mbps本身存储为一个单位，那么即使它也涉及时间成分，我们也需要某种方法将其直接与MB相关联。幸运的是，从能源到电力的转换（反之亦然）对我们来说是一件非常罕见的事情，因此我们的解决方案应针对所有其他棘手的示例进行优化，并希望也允许这个示例，但不要处理相关的问题。能源到电源是一种选择。

整蛊例如5： 这主要是3 + 4，我们可以同时拥有每千瓦$和$每千瓦时，所以利率同时面对电力和能源。

举个简单的例子： 有些转换非常容易，而这些转换是网络上大多数信息都可以处理的。1000 Wh = 1kWh等。与Therms和Decatherms或kW到MW等相同。在这里我不需要帮助，但请记住，我们约有70％的转换属于此类。

我对如何开始但不确定如何完成的想法：

1. 这显然很混乱，因此我建议我们选择一个标准的度量单位来存储每种商品和“使用类型”的所有数据。因此，对于电力，我们的标准能源单位为kWH，我们的标准动力单位为kW。因此，要转换为任何其他能源/功率单位，我们仅需要与标准之间的转换率，而不是每种可能的组合。如果我们需要将MW转换为W，我们总是可以通过将其转换为kW来实现。
2. 由于转换率可能取决于特定时间，因此我们必须允许存储与测量相关的时间。我怀疑我们不必担心这些转换率的变化快于每小时一次，甚至可以假设每天一次。
3. 由于转换率可能取决于发布的值，因此我们必须允许该值相对于度量存储的能力。我怀疑我们不必担心这些转换率的变化快于每小时一次，甚至可以假设每天一次。
4. 解决所有这些问题之后，我期望创建一个仅处理所有单位转换的Web服务。我不是要执行这些转换的SQL，而是可以做一些创造性的缓存，因此我并不是绝对要锤击这些表，但是有时它需要处理用户访问的网站中每页面加载约400个值的转换。我不确定这是否/如何重要。

我不知道应该在什么级别存储从未更改过的转换率与确实发生更改的转换率，以及如何以一种易于使用的方式快速访问这些转换率的方法，一起工作。

关于如何解决这个问题，甚至某些出版的阅读材料可能有帮助的想法？我正在使用SQL Server（即将成为SQL Azure），但这并不重要。正确表示这一点的模式就是我在这里遇到的问题。如果它像英寸和厘米一样简单，那很容易。但是这里存在转换率变化的问题。

您需要在设计中考虑一些因素：

1.测量需要时间戳记

确保所有测量都具有以下指示：

• 标量值
• 测量单位
• 测量的日期和时间

这将使您可以处理需要依赖于时间的转换计算的测量。

2.计量单位具有属性

每个度量单位都有一些不同的属性。显而易见的是指示性的，如代码和描述性名称。每个度量单位还需要保留几个关键的其他属性。（i）单位类型和（ii）转换为基本单位的因子。

第一个告诉您度量单位是长度，重量，能量，功率，货币等。它还应该告诉您基本度量单位是什么。您应该为每种单位类型选择一个。如果愿意，您可以使用诸如kWh之类的东西，但是如果您是我，我会坚持使用基本SI单位（如果适用）。

第二个告诉您需要将您的计量单位乘以什么才能达到基准。我提到这是您的UOM的属性，但实际上它必须在子表中。拥有此基本转换因子的子表的业务关键字是UOM，其基本单位类型和日期/时间的组合。我会在基本转换因子表上同时保留有效日期和到期日期/时间。这使您可以快速找到在任何特定时间点都适用的正确汇率。如果碰巧的价格没有变化，那就可以了。只需为一条记录使用最小排序有效日期和最大排序过期日期。

3.尝试以表格驱动一切都会使您发疯 ，难题的最后一步是确定从一种单位转换到另一种单位的计算。您可以尝试通过表驱动这种计算，但是最后，棘手的计算将使设计变得如此笼统（阅读起来既复杂又缓慢），以致于不切实际。而是，创建转换计算的代码表，并使用它来将一种单位类型链接到另一种单位类型。在某处的某些代码中执行实际计算。 您在任何给定的转换中使用哪段代码是代码表告诉您的。 计算的执行方式只是在代码中。您可以对各种简单的事情分别进行一次计算，例如面积需要两个长度，体积需要三个长度，而较难的东西（例如工作）则需要精力和时间。

当您弄清了设计的详细信息后，应将其写博客并返回此处发布链接！

您可以在其中使用视图或查询。一张表包含原始数据，另一张表包含您需要应用的转换率-如果要应用的转换率对时间或情况敏感，则可以包含日期或一些其他信息。然后创建一个查询或视图，通过将表连接在一起进行所需的转换。这样，您可以根据需要更改转化率值并重新计算。

假设场景的简单示例（PostgreSQL），您将有所不同：

CREATE TABLE join_test.amounts
(
  amount integer,
  unit character varying(10)
);

CREATE TABLE join_test."conversion"
(
  unit character varying(10),
  ratio integer
);

insert into join_test.amounts ( amount,unit) values (10 , 'dollar' );
insert into join_test.amounts ( amount,unit) values (10 , 'euro' );
insert into join_test.amounts ( amount,unit) values (15 , 'dollar' );
insert into join_test.amounts ( amount,unit) values (15 , 'euro' );

insert into join_test.conversion ( unit, ratio) values ('dollar', 2 );
insert into join_test.conversion ( unit, ratio) values ('euro', 3 );

-- create this as a view
select a.amount, c.ratio, a.amount * c.ratio as "result"
from    join_test.amounts a,
    join_test.conversion c
where a.unit = c.unit
and   c.unit = 'euro'
and   a.unit = 'euro'   ;