您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
您建议使用datetime或timestamp字段吗?为什么(使用MySQL)?
我在服务器端使用PHP。
当前回答
我总是将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的下限,例如存储出生日期。
其他回答
参考本条:
主要区别:
TIMESTAMP用于跟踪记录的更改,并在每次更改记录时进行更新。DATETIME用于存储不受记录更改影响的特定静态值。
TIMESTAMP也受不同时区相关设置的影响。DATETIME是常量。
TIMESTAMP在内部将当前时区转换为UTC进行存储,并在检索期间转换回当前时区。DATETIME无法执行此操作。
TIMESTAMP支持的范围:1970-01-01 00:00:01 UTC至2038-01-19 03:14:07 UTCDATETIME支持的范围:“1000-01-01 00:00:00”至“9999-12-31 23:59:59”
我总是使用Unix时间戳,只是为了在处理大量日期时间信息时保持理智,尤其是在调整时区、添加/减去日期等时。在比较时间戳时,这排除了时区的复杂因素,并允许您在服务器端处理(无论是应用程序代码还是数据库查询)中节省资源,因为您使用了较轻的算术,而不是较重的日期时间加减函数。
另一件值得考虑的事情:
如果您正在构建一个应用程序,那么您永远不知道您的数据可能会被如何使用。如果你最终不得不将数据集中的一堆记录与第三方API中的一堆项目进行比较,然后按照时间顺序排列,你会很高兴为你的行设置Unix时间戳。即使您决定使用MySQL时间戳,也要存储Unix时间戳作为保险。
我总是将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的下限,例如存储出生日期。
我建议不要使用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)中看到的所有这些花哨的数据类型几乎没有增加任何内容,并使您开始进入供应商锁定状态。
这取决于应用程序。
考虑由用户在纽约的服务器上设置时间戳,以便在桑海进行约会。现在,当用户在桑海连接时,他从东京的镜像服务器访问相同的预约时间戳。他将在东京时间看到这一任命,而不是原定的纽约时间。
因此,对于表示用户时间(如约会或日程)的值,datetime更好。它允许用户控制所需的确切日期和时间,而不考虑服务器设置。设置时间是设置时间,不受服务器时区、用户时区或夏时制计算方式变化的影响(是的,它会变化)。
另一方面,对于表示系统时间的值,如支付事务、表修改或日志记录,始终使用时间戳。将服务器移动到另一个时区或在不同时区的服务器之间进行比较时,系统不会受到影响。
时间戳在数据库上也更轻,索引速度更快。