请教个问题，为什么数据库的日期用字符串存，字符串格式是 20201027195800 这种

[VeryZero]

看了好几家公司的 Java 项目都有这么干的，一直想不通。

数据库是 Oracle，也有 MySQL 的。

除了这个以外，还有字符串做主键，AA0001 这种。

还有字符串做关联查询等等。

最骚的是字符串传参。。

感觉 Oracle 里的字符串是万能的。是他们太菜了还是我太菜了。。

[wpblank]

我们时间也是上述格式，用 bigint 存。我也不知道为啥。

[jingniao]

数据库原生 datetime 要注意时区
int 类型时间戳

[cmdOptionKana]

日期用字符串很常见，也是有一些好处。

[VeryZero]

@wpblank
@jingniao
@cmdOptionKana

你们说的整形存的可能是 unix 时间戳，这个很正常，特别是 PHP 的系统里比较常见，计算比较都很方便。

但是这是年月日时分秒格式的，比较计算啥的都要用函数。

不知道好处在哪，所以才问的。

退一步说就算这种年月日时分秒的格式有某方面的优势，也应该用整形存吧，用字符串真的不用考虑索引的感受吗

[CRVV]

本来就可以这么用，如果你要深究，就保存时间这件事情上，每个方法都会有缺点。

首先字符串就是任意长度的整数，没什么区别。

日期时间的存法很多，比如
1. 用 unix timestamp，缺点是人类不能一眼看出来那是哪天。
2. 用数据库内置的 datetime 类型，但 MySQL 的 datetime 有奇怪的行为还不能带时区。
3. 用楼主说的这种，存字符串类型。
4. 用楼主说的这种，存整数类型。

4 比 3 省 6 个 byte 的空间。
但是这个格式一定要从字符串转换过来，用的时候也必然要转回字符串，所以 3 比 4 节省一点 cpu 。

实际上 3 和 4 的差别是无关紧要的事情，没人在乎 6 个 byte，也没人在乎那一点点 cpu 。
但 1 和 2 的缺点是确实存在的。

[GopherDaily]

实话说的话，就是菜

[chendy]

当处理不好时区还有其他一些奇怪的问题的时候，字符串就是最优解，数字性能更好一些但是也更麻烦一点

[xcstream]

比如查找 10 点到 11 点的数据 ， 用 int 存就要每个日期计算一遍。

[chenluo0429]

1%的可能是有特殊需求，99%都是因为菜吧

[krixaar]

如果他们存“20201027T195800+0800”也就是再加点无关紧要的佐料是不是就觉得没问题了？毕竟如果确实只在东八区用，+0800 写不写都知道。

[ragnaroks]

这说明瓶颈在 web 应用上,不在数据库上

[opengps]

没什么菜不菜的，只是偷懒而已

[xuanbg]

对于接口来说，日期要么字符串传参，要么时间戳传参。还能有别的办法传参？反正我倾向于字符串传参，时间戳还得换算一下才能知道时间，不利于发现问题。

[blless]

写业务多了就会发现时间戳的好处了，尤其是处理一些面向海外的业务

[zsdroid]

时间戳不可读？加个虚拟列就好了

[wysnylc]

@GopherDaily #6 +1 就是菜
时间戳有时区而且索引比字符串要快得多,字符串是索引性能最低的,要不然要那么多整数类型干什么

[wilsonWei]

应该用带时区的 timestamp

[qiayue]

@wilsonWei 时间戳不分时区的吧

[no1xsyzy]

@xuanbg 有是有，json 的方式传{}或者传[]都可以的。
比如传 [2020, 10, 27, 19, 58, 00] 还比主题的格式更方便眼 parse
当然，ISO 8601 也是好的
只是觉得主题这样毫无 “肉眼解析锚点” 的方式确实不太行。
不过数据库是另一个问题，有日期格式优先日期格式，没有再看数据量级和需求综合分析，指不定最优方案是同时存储 timestamp 和字符串表示呢。

[GrayXu]

字符串不是显然解析开销比较大嘛。。