如果我将日期时间作为浮点数存储在数据库中,会有什么问题?

什么会咬你?第一个浮点数不是一个精确的数据类型,因此可能永远不应该用于任何需要精度的事情。接下来,float不会自动拒绝错误的日期。接下来,如果你想执行任何日期函数,你首先必须将数据转换回日期时间数据类型,这是对服务器资源的浪费。

你说你有一个很好的理由想这样做,但有了可能是什么的线索,我认为日期应该存储在处理它们的数据类型中。

这是一篇关于“揭秘SQL Server DATETIME数据类型”的好文章

http://www.sql-server-performance.com/articles/dev/datetime_datatype_p1.aspx

从阅读结果来看,日期时间似乎存储为2个4字节的整数,或者你可以使用二进制(8)

还有阿兰说的话。..维护的基本问题;当其他人加入该项目,并在数据库中看到datetime的浮点数,并试图对其做错事,或试图将其重构为正确的类型,或只是花几个小时仔细研究代码以找出到底发生了什么。通过广泛记录正在发生的事情以及为什么这样做,可以在一定程度上缓解整个维护问题,我强烈建议这样做。

SQLite使用一种时间格式(少数可用格式之一),其中(64位)双浮点数使用整数部分表示自纪元以来的天数,小数部分表示一天的分数。它似乎工作得很好。

看 SQLite Date and Time Functions “格式12是表示为浮点值的儒略历日数。”

Julian Dates

根据 this Julian Date Converter ,JD 99999999.99是CE 22666 12月20日11:59:59.1 UT星期四

精度损失为1。缺乏决心是另一个问题。

这是一个小问题,但浮点版本IEEE 754与VAX浮点。

你失去了一些精确度。我在SQL Server中测试了:

select getdate(), cast(getdate() as float), cast(cast(getdate() as float) as datetime)

您可以看到,如果重复运行此操作,转换过程中可能会损失多达4毫秒的时间。如果你的数据库支持smalldatetime这样的数据类型,你只需要精确到秒,那么你就可以消除这种差异。

select cast(0 as datetime), cast(0.5 as datetime)
1900-01-01 00:00:00.000 1900-01-01 12:00:00.000

使用浮点数的一个潜在缺点是,您将失去使用系统内置日期操作功能的能力。如果你只做区间计算,浮点可能没问题,但任何与日历相关的事情都可能需要重新设计轮子。

select
  to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as Date_Value,
  dump(sysdate) as Internals
from dual;

DATE_VALUE          INTERNALS                                                   
------------------- ------------------------------------------------------------
2009-05-28 09:51:12 Typ=13 Len=8: 217,7,5,28,9,51,12,0                          
1 row selected

如果你打算将这些数据存储为浮点数,我认为最好将自epoch以来的秒数存储为浮点,而不是将datetime存储为浮点将更好