假设您想将某物长 30 米，或 50 英尺，或温度为 50 开尔文，速度为每小时 50 公里的数据库写入数据库。 您将如何表示这些单位？
澄清两点：
【问题讨论】：
标签： database standards units-of-measurement
关系数据库设计的一个基本概念是，给定列中的所有值都应该代表某种逻辑兼容的数据类型。形式上，一列只有一个 type，类型中的任何两个值都可以在相等谓词中相互比较。这是类型论的关键部分。
因此，如果测量值不可比较，即长度与温度，则不应将它们存储在同一列中。
您可能想查看ISO 2955，“信息处理 - 表示 SI 和具有有限字符集的系统中的其他单位。”
另请参阅“Joe Celko's SQL Programming Style”，第 4 章，尺度和测量。
【讨论】：
关系理论认为每个 relvar（“表”）都有一个关联的谓词，用于定义其中的元组的含义。该谓词应该是数据库正式文档的一部分，这样任何实际查阅文档的人都不能有任何借口“误解了某些东西”（当然，除非文档不完整）。
在该谓词中包含单位的定义（例如，“人的长度......是英尺。”，“测量的温度是......开尔文”，......）实现了完整性并避免不得不诉诸于那些相当难看的属性（“列”）名称。
我不明白为什么“仅存储数字”（以所有用户都同意的标准单位）会“不容易”。
如果 foobaricity 作为一个单位存在，并且有人提出了一个新的单位 fluffyperception，那么无论如何，某人首先必须正式建立 foobaricity 的数量和 fluffyperception 的数量之间的对应关系，否则他所说的任何东西都不会/可以被理解任何人。
编辑
我看到这个添加： “我需要保留原始单位的信息。”
没有什么能阻止你这样做。 “规范化”值旁边的两个额外列（原始数量和原始单位名称）。您可以根据需要将“原始单位名称”限制为强或松。
【讨论】：
您是否有特定的理由以不同类型的单位存储数量，而不是转换为一些“规范”单位（例如，公制）？插入数据时，您会将输入数量转换为规范单位。在读取数据时，您可以转换为您需要的任何输出单位。
这种方法在很多方面都比以不同单位存储数据更简单，但是您会丢失有关指定数据的原始单位的信息。
【讨论】：
我会在列名中包含单位（例如 LengthInMeters、WeightInKilograms、AnnoyingnessInFishSlapsPerSecond 等），然后将数字存储在列中。
理想情况下，能够将单位定义为列的（正确）属性会很好，但我不知道有任何数据库允许这样做。由于列名中包含单位，未来的开发人员很难对此感到困惑。
我遇到了在第二列中包含单位的 DB 解决方案，但由于没有标准化的表示单位的方式，这最终成为具有“ft.”、“feet”、“Feet”等值的文本字段" 等，或者是存储可能单位（也是文本）的表的 FK。无论哪种方式，运行 SUM 或 AVG 查询（或任何计算）都会成为一场噩梦，尤其是当您允许将具有不同单位的值存储在同一列中时。
【讨论】：