在MySQL中处理公元1000年之前的日期的最佳方法？

我正在为记录扩展到公元1000年之前的记录创建数据库，但是MySQL Date和DateTime字段仅支持从1000开始的日期。

有没有一种方法比使用bigint类型在1970年1月1日之前/之后使用Unix时间戳计数秒数，或者切换到支持更大日期范围的数据库软件更方便？

mysql database-design best-practices timestamp date-format

— 戴维·勒鲍尔
source

在SO上可以很好地回答这一问题：stackoverflow.com/q/2487543/514119

— stanleykylee 2011年

@stanleykylee感谢您指出这一点。问题是不同的，但是问题出现在注释中，随后按照“选择参考日期并使用数字字段”的方式回答，但要注意“编码起来很繁琐，但是很简单”我的问题主要是问这是否是最好的选择。

— David LeBauer 2011年

啊，我莫名其妙地错过了那个问题。请允许我

— 面对面

Answers:

一种替代方法是将日期的每个部分存储在一个数字字段中。因此，您将拥有三个字段：

year  SMALLINT     # Store positive values for AD and negative for BC years.
month TINYINT
day   TINYINT

这样，它仍然是人类可读的。MySQL中不同数值数据类型的值范围可在“数值类型概述”中找到。存储要求可从“ 数据类型存储要求”中获得。

— dabest1
source

我想给它一个+1，但是我很确定日期逻辑将是可怕的吧？

— 卡米洛·马丁

如何在单个字段中以数字格式存储日期，例如2015-10-12 10:12:05

— atpatil11 '16

对于需要非常旧（甚至将来甚至很远）日期的应用程序，本机RDBMS日期数据类型将不起作用。

如果您是我，我会为本地存储使用字符串类型，并坚持使用重要位置格式，例如：+ YYYY-MM-DD以适应BC / AD和任何可预见的历史或合理的未来日期。

如果可能有帮助，则可以构建一个库类，将您的内部存储格式转换为UI层更合适的格式。如果您选择的语言支持数据库中要包含的日期，则甚至可以包括转换为本地日期类型的库函数。

— 乔尔·布朗
source

如果您使用的是SQL Server 2008+，则DATETIME2是答案。日期范围：公元1月1日至9999年12月31日。

— 尼克·查马斯

好建议。对于其他系统，我还建议使用CHECK约束来强制日期字符串格式。MySQL，MySQL 不强制执行 CHECK约束。

— Nick Chammas，

@Nick对于SQL Server 2008+中的DATETIME2表示同意，（我想念1753年），但是OP从MySQL开始作为他的根基。此外，甚至DATETIME2也会在您需要向日历添加公元前1年12月31日时掉下来：）

— Joel Brown

您始终可以添加BIT或BOOLEAN列以指示日期极性。:)当然，如果您这样做，那么您可以在那些“ BC”日期执行计算。谁知道在处理“伪造”的BC日期时，图书馆功能通常会错过哪些由我们执行的日历调整……

— Nick Chammas

马克，我建议使用字符串的原因是，只要您正确地设置字符串，它就可以被人类阅读（甚至在某种程度上可编辑），而无需进行任何处理，并且可以相对轻松地构造特殊的日期操作函数。将日期存储为数字是非常非常不便的，除非您拥有一个可以为人类解释这种编码的函数库。当然，当有这样的库时，将日期编码为数字会更加明智。

— 乔尔·布朗

在表中以数字格式存储日期的单个浮动字段（例如2015-10-12 10:12:05）将如何存储在20151012中。101205.在单个字段上进行排序总比拥有3个或更多字段更好不同的领域。

以上逻辑在少数情况下不起作用。因此，我们考虑1天= 86400秒将日期转换为秒。BC日期使用负数。它按预期工作。

— atpatil11
source

BC为负数？

— 罗伯·塞奇威克

151012和150819都将出现在15AD，-151109将会出现在15BC

— Rob Sedgwick