您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
当前回答
TIMESTAMP是四个字节,而DATETIME是八个字节。时间戳在数据库上也更轻,索引速度更快。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模式。DATETIME是常量,而TIMESTAMP受时区设置的影响。
其他回答
我是基于语义做出这个决定的。
当我需要记录(或多或少)固定时间点时,我使用时间戳。例如,当记录被插入到数据库中时,或者当发生某些用户操作时。
当可以任意设置和更改日期/时间时,我使用datetime字段。例如,当用户可以保存以后的更改约会时。
当您有来自不同国家、不同时区的游客时,TIMESTAMP非常有用。您可以轻松地将TIMESTAMP转换为任何国家/地区的时区
在使用MySQL和PHP时,我总是使用Unix时间戳。这主要是因为PHP中的默认日期方法使用时间戳作为参数,因此不需要解析。
要获取PHP中当前的Unix时间戳,只需执行time();在MySQL中执行SELECT UNIX_TIMESTAMP();。
在我的例子中,我将UTC设置为所有事物的时区:系统、数据库服务器等,只要我能做到这一点。如果我的客户需要另一个时区,那么我会在应用程序上配置它。
我几乎总是喜欢时间戳而不是日期时间字段,因为时间戳隐含地包含时区。因此,由于从不同时区的用户访问应用程序的那一刻起,您希望他们在本地时区中查看日期和时间,因此与数据保存在datetime字段中相比,此字段类型更容易实现。
另外,在将数据库迁移到另一个时区的系统的情况下,我会更加自信地使用时间戳。更不用说在计算两个时刻之间的差异时可能出现的问题,这两个时刻间的总时间变化较大,并且需要1小时或更短的精度。
总之,我看重时间戳的优点:
可在国际(多时区)应用程序上使用在时区之间轻松迁移很容易计算差异(只需减去两个时间戳)不用担心夏天的约会
出于所有这些原因,我选择了UTC和时间戳字段。我避免头痛;)
DATETIME不携带时区信息,并且将始终显示与会话有效的时区无关的时区,除非您明确更改它,否则默认为服务器的时区。但是,如果我使用NOW()之类的函数而不是“2020-01-16 12:15:00”之类的文字来初始化DATETIME列,是本地化到会话时区的当前日期和时间。
相比之下,TIMESTAMP确实隐式地携带时区信息:当您使用值初始化TIMESTAMP列时,该值在存储之前会转换为UTC。如果存储的值是文本,例如“2020-01-16 12:15:00”,则出于转换目的,它被解释为在会话的当前时区中。相反,当显示TIMESTAMP列时,它将首先从UTC转换为会话的当前时区。
什么时候使用一个或另一个?案例研究
一个社区剧团的网站正在播放几场正在售票的戏剧演出。这些演出的日期和时间将显示在下拉列表中,希望购买演出门票的客户将从中选择一个。数据库列performance_date_and_time为DATETIME类型是有意义的。如果演出地点在纽约,则有一种理解,即有一个隐含的时区(“纽约当地时间”),理想情况下,我们希望日期和时间显示为“2019年12月12日晚上8点”,而不考虑会议的时区,也不必麻烦进行任何时区转换。
另一方面,一旦2019年12月12日晚上8点的演出开始,我们可能不再想出售门票,因此不再在下拉列表中显示该演出。因此,我们想知道“2019-12-12 20:00:00”是否已发生。这将证明有一个TIMESTAMP列,将会话的时区设置为“America/New_York”,并将会话time_zone设置为“American/New_约克”,然后将“2019-12-12 20:00:00”存储到TIMESTAMP栏中。从此,我们可以通过独立于当前会话时区将此列与NOW()进行比较来测试性能是否已开始。
或者,为这两个单独的目的设置DATETIME和TIMESTAMP列可能是有意义的。或者不是。显然,任何一个都可以达到这两个目的。如果只使用DATETIME列,则在与NOW()进行比较之前,必须将当前时区设置为本地时区。如果只使用TIMESTAMP列,则必须在显示该列之前将会话时区设置为本地时区。