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