您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
当前回答
主要区别在于DATETIME是常量,而TIMESTAMP受时区设置的影响。
因此,只有当您已经或者将来可能已经跨时区同步集群时,这才是重要的。
简单地说:如果我在澳大利亚有一个数据库,并转储该数据库以同步/填充美国的数据库,则TIMESTAMP将更新以反映新时区中事件的实时,而DATETIME仍将反映非时区中事件发生的时间。
DATETIME的一个很好的例子是在Facebook中使用TIMESTAMP,在那里他们的服务器从来都不太确定跨时区发生的时间。有一次,我正在进行一次谈话,在谈话中,时间说我在消息实际发送之前回复消息。(当然,如果时间是发布的而不是同步的,这也可能是由于消息传递软件中的时区转换错误造成的。)
其他回答
我总是将DATETIME字段用于除行元数据(创建或修改日期)之外的任何内容。
如MySQL文档中所述:
DATETIME类型在您需要同时包含日期和时间信息的值时使用。MySQL以“YYYY-MM-DD HH:MM:SS”格式检索并显示DATETIME值。支持的范围为“1000-01-01 00:00:00”到“9999-12-31 23:59:59”。...TIMESTAMP数据类型的范围为“1970-01-01 00:00:01”UTC到“2038-01-09 03:14:07”UTC。它具有不同的财产,具体取决于MySQL版本和服务器运行的SQL模式。
一般情况下,您很可能会达到TIMESTAMP的下限,例如存储出生日期。
这里的许多答案都建议将时间戳存储为时间戳,以防必须表示定义良好的时间点。但是,如果您按照惯例将所有时间点都存储在UTC中,那么您也可以使用datetime获取时间点。
2016+:我建议您将Mysql时区设置为UTC,并使用DATETIME:
任何最近的前端框架(Angular 1/2、react、Vue…)都可以轻松自动地将UTC日期时间转换为本地时间。
此外:
DATETIME现在可以自动设置为当前时间值。如何设置MySQL DATETIME列的默认值?与人们可能认为的相反,DATETIME比TIMESTAMP快,http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-myisam/TIMESTAMP仍然限于1970-2038
(除非您可能更改服务器的时区)
AngularJs示例
// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...
// font-end Output the localised time
{{item.my_datetime | date :'medium' }}
此处提供所有本地化时间格式:https://docs.angularjs.org/api/ng/filter/date
时间戳数据类型存储日期和时间,但使用UTC格式,而不是像datetime那样使用当前时区格式。当您获取数据时,时间戳再次将其转换为当前时区时间。
所以假设你在美国,从一个时区为美国的服务器获取数据,然后你将根据美国时区获取日期和时间。时间戳数据类型列总是在其行更新时自动更新。因此,跟踪上次更新特定行的时间可能很有用。
有关更多详细信息,您可以阅读博客文章Timestamp Vs Datetime。
我建议不要使用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)中看到的所有这些花哨的数据类型几乎没有增加任何内容,并使您开始进入供应商锁定状态。