4

我需要设计一个大多数属性都有单位的数据库表。例如：

Readings
--------

id   load (kW)   fuel_consumption (tonnes) - etc
1    1154        89.4
2    1199        54.2

在设计中捕捉单位的推荐方法是什么？例如，我可以：

  • 在属性名称中存储单位，例如 load_kW 和fuel_consumption_tonnes
  • 将单位存储在单独的表中，例如，每个值都成为另一个表的外键，其中包含值和单位列。
  • 存储在数据库之外：例如在业务逻辑中，或在文档中
  • 还有其他人吗？

我碰巧在使用 MySQL，但我认为这是一个通用的数据库规范化问题。

4

2 回答 2

2

这最终取决于您打算或需要对您的数量做什么。

如果（在不太可能的情况下）您将要做的只是记录值以供以后反流，那么您对单位做什么并不重要，因为标量值对您的模型没有语义意义。

更有可能是系统中的标量对您的系统具有一定的重要性。例如，这可能是因为您正在对它们执行计算。在这种情况下，您的单位非常重要。

您需要自己回答的下一个问题是，单位是否始终保持一致且不得更改。在大多数情况下，我会说这是一个冒险的结论。这可能是您通过系统强加的业务规则，但业务规则有一个令人讨厌的改变习惯。

出于这个原因，我建议使用代表实际测量的每个标量存储一个测量单位。以这种方式显式会占用一些磁盘空间，但它会为您提供清晰性和灵活性。

我过去做过的事情是扩展度量单位模型以包括 UOM 类型，如长度、温度、体积、时间等。保留将每个 UOM 映射到 UOM 类型的表允许您还存储转换因子. 这样，如果有人带着必和必拓和磅读数来找您，您就会知道如何处理它以及如何将其与您以千瓦和吨为单位的典型条目进行比较。

于 2012-10-25T14:12:10.467 回答
1

有趣的问题...

有两条明显的路线：

id   load_kW     fuel_consumption_tonnes
--------------------------------------------------
1    1154        89.4
2    1199        54.2

这对人类来说很容易阅读，而且相当合乎逻辑。但是，如果某些读数以“公斤”为单位，而其他读数以“吨”为单位，则您必须将这些读数转换为适合“读数”表；这个过程必须是“无损的”，并且是幂等的。例如，“89403 公斤”的读数不是“89.4 吨”，即使企业为了方便可能会选择从公斤到吨四舍五入。通常会发生一些违反直觉的四舍五入的事情......

如果是这种情况，您可以更改架构：

id      load load_unit    fuel_consumption fuel_consumption_unit
--------------------------------------------------
1    1154  kW          89403              kg
2    1199  kW          54.2               t

如果需要，使用“单位”表：

unit_id    unit_name
--------------------
kg         kilogramme
t          Tonne

但是，此模型容易出现人为故障 - 很容易更改“load_unit”列而不修改“load”列，从而破坏数据。您实际上无法对数据模型做任何事情来避免这种情况。它还使常见查询变得相当棘手：想象一下尝试以一致的度量单位检索“负载”的总数。

我建议在这种情况下，您有两个表：“raw_readings”，原始数据采用上述格式，“normalized_readings”，通过将所有读数转换为一致的测量单位来填充。

于 2012-10-25T15:22:13.793 回答