您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
当前回答
主要区别在于DATETIME是常量,而TIMESTAMP受时区设置的影响。
因此,只有当您已经或者将来可能已经跨时区同步集群时,这才是重要的。
简单地说:如果我在澳大利亚有一个数据库,并转储该数据库以同步/填充美国的数据库,则TIMESTAMP将更新以反映新时区中事件的实时,而DATETIME仍将反映非时区中事件发生的时间。
DATETIME的一个很好的例子是在Facebook中使用TIMESTAMP,在那里他们的服务器从来都不太确定跨时区发生的时间。有一次,我正在进行一次谈话,在谈话中,时间说我在消息实际发送之前回复消息。(当然,如果时间是发布的而不是同步的,这也可能是由于消息传递软件中的时区转换错误造成的。)
其他回答
我是基于语义做出这个决定的。
当我需要记录(或多或少)固定时间点时,我使用时间戳。例如,当记录被插入到数据库中时,或者当发生某些用户操作时。
当可以任意设置和更改日期/时间时,我使用datetime字段。例如,当用户可以保存以后的更改约会时。
在遇到许多与时区相关的问题和错误后,我停止在应用程序中使用datetime。在大多数情况下,IMHO使用时间戳优于datetime。
当你问什么时候?答案类似于“2019-02-05 21:18:30”,这不是完整的,也不是定义的答案,因为它缺少另一部分,在哪个时区?华盛顿?莫斯科北京?
使用不带时区的日期时间意味着您的应用程序只处理一个时区,但时间戳为您提供了日期时间的好处,以及在不同时区显示相同精确时间点的灵活性。
以下是一些会让您后悔使用datetime并希望将数据存储在时间戳中的情况。
为了客户的舒适,您希望根据他们首选的时区向他们显示时间,而不让他们做数学运算,并将时间转换为有意义的时区。您只需更改时区,所有应用程序代码都将相同。(实际上,您应该始终在应用程序开始时定义时区,或者在PHP应用程序中定义请求处理)SET time_zone=“+2:00”;您改变了所居住的国家,并继续维护数据,同时在不同的时区查看数据(而不更改实际数据)。您接受来自世界各地不同客户的数据,每个客户都会在自己的时区中插入时间。
简言之
datetime=应用程序支持1个时区(用于插入和选择)
timestamp=应用程序支持任何时区(用于插入和选择)
这个答案只是为了强调时区的灵活性和易用性,它没有涵盖任何其他差异,如列大小、范围或分数。
TIMESTAMP需要4个字节,而DATETIME需要8个字节。
在MySQL 5及以上版本中,TIMESTAMP值从当前时区转换为UTC进行存储,并从UTC转换回当前时区进行检索。(这仅适用于TIMESTAMP数据类型,而不适用于DATETIME等其他类型。)
默认情况下,每个连接的当前时区是服务器的时间。可以根据每个连接设置时区,如MySQL Server时区支持中所述。
我建议不要使用DATETIME或TIMESTAMP字段。如果你想将一个特定的日子作为一个整体来表示(比如生日),那么就使用DATE类型,但是如果你要更具体一些,你可能会对记录一个实际的时刻感兴趣,而不是一个时间单位(日、周、月、年)。不要使用DATETIME或TIMESTAMP,而是使用BIGINT,只需存储自epoch以来的毫秒数(如果使用Java,则为System.currentTimeMillis())。这有几个优点:
避免供应商锁定。几乎每个数据库都以相对类似的方式支持整数。假设您想移动到另一个数据库。您想担心MySQL的DATETIME值之间的差异以及Oracle如何定义它们吗?即使在不同版本的MySQL中,TIMESTAMPS也具有不同的精度级别。直到最近,MySQL才支持时间戳中的毫秒。没有时区问题。这里有一些关于不同数据类型的时区的见解。但这是常识吗?你的同事会花时间学习吗?另一方面,很难将BigINT更改为java.util.Date。使用BigINT会导致很多时区问题被搁置一旁。无需担心范围或精度。你不必担心未来日期范围会缩短什么(TIMESTAMP只适用于2038年)。第三方工具集成。通过使用整数,第三方工具(例如EclipseLink)与数据库的接口很简单。并非所有第三方工具都会像MySQL一样理解“datetime”。如果您使用这些自定义数据类型,想尝试在Hibernate中确定是否应该使用java.sql.TimeStamp或java.util.Date对象?使用基本数据类型使第三方工具的使用变得微不足道。
这个问题与如何在数据库中存储货币值(即1.99美元)密切相关。你应该使用十进制,还是数据库的货币类型,或者最糟糕的是双精度?由于上面列出的许多相同原因,所有三种选择都很糟糕。解决方案是使用BIGINT将货币的价值存储为美分,然后在向用户显示价值时将美分转换为美元。数据库的工作是存储数据,而不是插入数据。您在数据库(尤其是Oracle)中看到的所有这些花哨的数据类型几乎没有增加任何内容,并使您开始进入供应商锁定状态。