1

我有一些我正在尝试存储的死亡数据，并且我正在尝试提出一个合理的方案来存储该人死亡时的年龄。

我没有他们中的任何一个的 DoB 数据，但我确实有一般的死亡日期（尽管并不总是非常精确），并且我有关于他们死亡年龄的不同准确性的数据。

一些典型的源数据可能是：

20 至 29 岁（或“20 多岁”）
5 岁
2 个月大
40 天大
成人
儿童
老人

我通常将其存储在三个字段中...

age_min（整数年）
age_max（整数年）
age_category（枚举 - 婴儿、儿童、成人、老人）

...但显然这并不能很好地捕捉到 2 个月大或 40 天大的数据，在我当前的模式中，这两者都会简单地以 0 年结束，这会不必要地丢弃信息。

数据库对于已知信息的精确度是诚实的，这一点非常重要。因此，例如，将 2 个月转换为 60 天将是一件坏事，因为它暗示了源数据未提供的精度水平 - 将其转换为 60-90 天可能没问题。

我还考虑添加一个单位字段，所以我有......

age_min (integer)
age_min_unit (enum - 天、月、年)

但这样做的问题是它使比较烦人。24 个月 == 2 年，但处理这个问题只会使很多代码比我怀疑的要复杂得多。

我可以以天为单位存储所有年龄，有最小值和最大值，但随后复杂性变成了将其转换回人类可读的东西，这种东西并不笨重，也没有比我实际拥有的精度更高。

因此，例如，40 天可能最终会在 1 个月、10 天时呈现，这实际上比 40 天的精确度要低一些。

4

3 回答 3

1

好的，只需添加它以供将来使用

您能否尝试在天数内使用 age_min 和 age_max 并且还携带一个字段作为“human_readable_age_text”，其内容为“40 天”

于 2013-08-14T14:10:28.833 回答
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.
于 2014-01-06T03:06:56.833 回答
0

将值存储为 min+max+unit。'adult','child'... 等可以表示为一个年龄单位，其最小值和最大值将被忽略。

然后你需要找到哲学问题的答案，比如“谁更大：孩子还是 5 到 12 岁的人？”。

当您对所有可能的年龄类型组合的答案有答案时，您将能够判断是否可以使用年龄的规范表示（例如天数）进行比较。

如果可能的话 - 您可以添加一个以天（或秒，或其他......）为单位的年龄的附加字段，以用于比较/排序。可以使用触发器或在应用程序中计算比较字段。

如果不可能 - 您将需要一个自定义比较器进行排序，afaik 无法在 MySQL 中完成，因此您可能必须在应用程序中进行所有排序和比较。

于 2013-08-14T14:11:07.180 回答