0

我正在构建一个应用程序，该应用程序将存储许多关于人的“标记”（体重、身高、血压等），并且由于用户对他们想要在 I 中测量事物的度量单位都有不同的期望将需要以一种聪明的方式解决 UOM 的问题。我想知道是否就如何最好地存储这些信息达成了共识。我正在考虑的示例如下（在每种情况下，假设前端都捕获标记和与捕获关联的 UOM）：

  1. 公制转换。转换为公制等效值并存储原始 UOM 的值，但仅存储公制测量值（原始测量值不会丢失，尽管转换中可能会出现一些小数精度）
  2. 存储两者。存储标记，捕获的 UOM，然后转换为公制并存储。这使得对度量数量的“同类”SQL 查询变得简单，同时完美地保留了原始标记的精度，但它显然更占用存储空间。我想插入的成本也会稍高一些，因为需要转换为公制（但我想这无关紧要）。

对我来说，精度损失并不重要，除了它可能产生的不和谐的用户体验。想象一下，如果用户放入 160 磅，然后看到它报告为 159.99 磅；这将是相当令人不安的，并会导致人们不相信这个系统。我怀疑在大多数转换中，尽管我可以返回相同的数字，而无需过多地增加数据库中的精度大小。不过，这种感觉只是我阳光般的乐观，而不是我已经测试过的东西。

4

1 回答 1

1

存储两者都感觉是个坏主意。您必须确保这些值保持一致，并且违反 DRY（不要重复自己）原则。

您混淆了存储和演示。如果您要存储重量，那么您应该存储为一种表示形式，然后以用户需要的任何表示形式呈现（例如，公斤、吨、吨、克、石头、磅、盎司等）

您可以将单位与大小一起存储（例如 10 公斤、4 石头等），但这会使比较产生问题，例如小于 2 盎司的实体的 SQL 查询必须执行转换。我认为在演示时执行 UOM 转换是一种一致且直观的解决方案。

于 2012-12-11T09:38:14.743 回答