我有一些关于我试图存储的死亡事故的数据，我正试图找出一个合理的方案来存储死亡时的年龄。
我没有其中任何一个的DoB数据，但我确实有死亡日期（虽然并非总是非常精确），而且我的死亡年龄的数据也不同。
一些典型的源数据可能是：
20至29岁之间（或“20多岁”）中 5岁
2个月大 40天大 成年人 孩子
老年
我通常将其存储在三个领域......
age_min（整数年）
age_max（整数年）
age_category（enum - 婴儿，儿童，成人，老人）
...但很明显，这并不能很好地捕捉2个月或40天的旧版本，这两个版本在我当前的架构中最终都会被淘汰为0年，这会不必要地丢弃信息。
数据库对于了解信息的精确度是非常重要的。例如，将2个月转换为60天将是一件坏事，因为它暗示了源数据未提供的精确度 - 将其转换为60-90天可能没问题。
我还考虑添加一个单位字段，所以我有......
age_min（整数）
age_min_unit（枚举 - 天，月，年）
但问题是它使比较烦人。 24个月== 2年，但处理这个问题只会让很多代码比我怀疑它要复杂得多。
我可以用几分钟和一分钟来存储所有年龄段，但是后来复杂性变成了人类可读的东西，这种东西并不笨重，并且表达的精度不如我实际的高。
因此，例如，40天可能最终会在1个月内呈现，10天实际上比说40天更精确。
答案 0 :(得分：1)
好的只是为将来添加答案
你可以尝试在几天内使用age_min和age_max，还可以携带一个字段作为“human_readable_age_text”读取，比如说“40天”
答案 1 :(得分：1)
去过那里，做到了。最不明确且最容易处理的是将所有内容转换为天数并添加+/-容差。这样，所有内容都可以存储在2个字段中，并涵盖所有情况。显然你必须在显示之前转换成人类可读的格式。
如果您有出生日期和死亡日期，则容差变为0。
因此，以下输入值将产生指示的存储值。
5 years: 2007 183 (ie. 5.5 x 365 = 2007 days. 365/2 = +/-183 days.)
2 months: 75 15
9 years 7 months: 3512 15
child: First value is midpoint of your preferred "child" age range in days. (1-12?, 3-18?). Tolerance is half that.
baby: Same again. Decide on what constitutes a "baby" (0-2?) and generate the values accordingly.
答案 2 :(得分：0)
将值存储为min + max + unit。 '成人'，'孩子'......等可以表示为忽略最小值和最大值的年龄单位。
然后你需要找到哲学问题的答案，比如“谁是老年人：一个孩子或一个5到12岁的人？”。
如果您对所有可能的年龄类型组合的答案有所了解，您将能够判断是否可以使用年龄（例如天）的规范表示进行比较。
如果可能的话 - 您可以添加一个额外的字段，其中包含用于比较/排序的天数（或几秒或某些......）。比较字段可以使用触发器计算，也可以在应用程序中计算。
如果不可能 - 你需要一个自定义的比较器来进行排序，这在MySQL中无法完成，所以你可能不得不在应用程序中进行所有的排序和比较。