将日期存储为整数答案

【问题标题】：Storing date as integer将日期存储为整数
【发布时间】：2022-04-12 06:01:52
【问题描述】：

我遇到了一个数据库架构（即时消息，http://www.9lessons.info/2013/05/message-conversation-database-design.html），其中消息的日期 + 时间不是以时间戳的形式存储的，而是以整数形式存储的，例如 123984347439。

这有什么意义？
我发现了一些将日期存储为整数的资源，例如 20151009。与数据库的本地日期 + 时间特定格式相比，这种方法的优缺点是什么？

【问题讨论】：

时间戳是一个整数。自“1970-01-01 UTC”以来的秒数。它可能会被您首选的 SQL 工具显示为“日期时间”。但是，在内部它是一个整数。
@RyanVincent，你能告诉消息来源吗？
我好喜欢google：网上搜索：'Mysql timestamp internal storage'。返回：11.7 Data Type Storage Requirements。在页面上找到timestamp 返回：4 bytes 这是一个可能无符号的整数。
@RyanVincent，有点嘲讽总是好的。 ;) 我知道那个链接，瑞恩。令我困惑的是为什么你认为它是一个整数？仅仅因为它存储4个字节？
不是在嘲笑！正在演示如何快速找到东西！我很抱歉给人以“嘲弄”的印象。我经常在这里——我想被认为是“乐于助人”而不是“嘲弄”。 ;-/

标签： mysql database database-design

【解决方案1】：

当存储为整数时，时间戳不依赖于服务器的任何时区设置。当您向 MySQL 服务器发送日期时，如果列类型为 timestamp，它将尝试将其转换为 UTC 进行存储。当它拉出日期时，它将执行相同的转换。

你可以阅读它in the manual, 5th paragraph。

MySQL 将 TIMESTAMP 值从当前时区转换为 UTC 存储，并从 UTC 返回到当前时区进行检索。（这不会发生在其他类型，例如 DATETIME。）默认情况下，每个连接的当前时区是服务器的时间。

保存整数后，这不会发生。

优点：

您不依赖服务器的时区

缺点：

如果不先使用FROM_UNIXTIME() 执行转换，您将无法轻松使用日期函数
手动读取数据时，数字不会告诉您有问题的日期。 timestamp 列对其进行格式化，以便您可以毫无问题地理解日期

更新：我不知道存储不是 unix 时间戳 的整数有什么好处。存储诸如20151009 之类的日期对应于10.09.2015 - 如果没有进一步的信息，我看不出有任何用途，所以我的个人意见归结为设计这样一个系统的人要么不太了解日期和处理它们，或者应用程序本身存在某种尴尬的业务逻辑，需要这样格式化的日期才能工作。底线是我个人不会使用它。我会坚持适用于所有人的成熟标准。

【讨论】：

我和你有类似的看法。问题是一些数据仓库专家（例如 Ralph Kimball）提倡使用日期作为整数，但我找不到真正的原因......
timestamp 在内部是一个整数。它需要 4 个字节，就像 MySQL int 类型一样（除非指定秒数，因此时间戳可能需要更多时间）。 timestamp 类型的用处是巨大的。如果不是，就不会有这样的数据类型，我们都会使用其他东西。

【解决方案2】：

从您链接的帖子看来，该行正在存储Unix timestamp。

这允许您将值存储为整数，同时还允许方法调用使用from_unixtime() 检索人类可读的日期所以如果需要，您可以调用SELECT from_unixtime(time) ASdateFROM conversation where user_id_fk = '3' 并检索类似2007-11-30 10:30:19 的值结果。

要回答您关于优缺点的问题，存储为整数的最大优点是比较整数比日期时间快得多。但是，当存储为 Unix 时间戳时，有一些警告（缺点）。在比较 unix_time = '1106475000' 和 date_field = '2005-01-23 10:10:00 时，整数实际上更快；但是，当您需要将整数（Unix 时间戳）与人类可读的时间戳进行比较时，就会出现问题。因为您需要在代码或查询中提前将该值转换为 Unix 时间戳，所以它会占用一些额外的资源，或者在查询的情况下它比本地日期比较慢得多。所以现在这个 int 比较 unix_time = UNIX_TIMESTAMP('2005-01-23 10:10:00') 比 date_field = '2005-01-23 10:10:00 慢很多。

因此，这实际上取决于您的服务器端代码如何利用存储为整数的速度。同样由开发人员决定这种速度是否值得在 sql server 和应用程序之间进行额外的抽象。

Here is some more information on date/integer comparisons in innodb.

Here is some more information on date/integer comparisons in myisam.

【讨论】：

【解决方案3】：

这很可能是一个以秒为单位的时间戳，从一个选定的时期（开始日期和时间）开始。有一些标准时间戳，例如Unix timestamps
在某些简单的情况下，将日期存储为整数可能会加快日期计算/比较，因为 mysql 和处理应用程序都不需要将基础数据转换为日期格式。它还可以为您的 HD 节省一些空间。缺点是不能使用内置的日期管理功能。因此，如果您想要执行复杂的计算，那么您可以编写自己的函数来执行这些操作，或者您需要将整数转换回日期格式。

【讨论】：

将其与将日期存储为 13 个字符的字符串的 Oracle DB 进行比较 - 我不知道他们为什么这样做。整数存储更紧凑，更容易/更快地排序和处理。事实上，每当我必须在 Oracle 中存储 Date 时，我都会让 Java 代码将其转换为 int，并存储一个 int 时间戳而不是原生 Oracle 日期。当然，当你执行原始 SQL 时它看起来并不好，但是使用 JPA/JDO，我现在几乎不需要运行原始 SQL。 SQL 是数据库世界的“汇编器”；）

【解决方案4】：

好处是当您实际上不需要日期或时间时 - 例如当您存储人们的出生日期并且只是将它们用作匹配值时 - 实际上并不将它们用作日期并且您不想存储字符串。

【讨论】：