请教个问题，为什么数据库的日期用字符串存，字符串格式是 20201027195800 这种
VeryZero · 2020-10-27 20:05:48 +08:00 · 4345 次点击这是一个创建于 1495 天前的主题，其中的信息可能已经有所发展或是发生改变。
看了好几家公司的 Java 项目都有这么干的，一直想不通。
数据库是 Oracle，也有 MySQL 的。
除了这个以外，还有字符串做主键，AA0001 这种。
还有字符串做关联查询等等。
最骚的是字符串传参。。
感觉 Oracle 里的字符串是万能的。是他们太菜了还是我太菜了。。
 |
1
wpblank 2020-10-27 20:13:20 +08:00 via iPhone
我们时间也是上述格式，用 bigint 存。我也不知道为啥。
|
 |
2
jingniao 2020-10-27 20:17:17 +08:00 via Android
数据库原生 datetime 要注意时区
int 类型时间戳 |
 |
3
cmdOptionKana 2020-10-27 21:00:43 +08:00
日期用字符串很常见，也是有一些好处。
|
 |
4
VeryZero OP @wpblank
@jingniao @cmdOptionKana 你们说的整形存的可能是 unix 时间戳，这个很正常，特别是 PHP 的系统里比较常见，计算比较都很方便。 但是这是年月日时分秒格式的，比较计算啥的都要用函数。 不知道好处在哪，所以才问的。 退一步说就算这种年月日时分秒的格式有某方面的优势，也应该用整形存吧，用字符串真的不用考虑索引的感受吗 |
 |
5
CRVV 2020-10-27 21:10:36 +08:00 via Android  7
本来就可以这么用，如果你要深究，就保存时间这件事情上，每个方法都会有缺点。
首先字符串就是任意长度的整数，没什么区别。 日期时间的存法很多，比如 1. 用 unix timestamp，缺点是人类不能一眼看出来那是哪天。 2. 用数据库内置的 datetime 类型，但 MySQL 的 datetime 有奇怪的行为还不能带时区。 3. 用楼主说的这种，存字符串类型。 4. 用楼主说的这种，存整数类型。 4 比 3 省 6 个 byte 的空间。 但是这个格式一定要从字符串转换过来，用的时候也必然要转回字符串，所以 3 比 4 节省一点 cpu 。 实际上 3 和 4 的差别是无关紧要的事情，没人在乎 6 个 byte，也没人在乎那一点点 cpu 。 但 1 和 2 的缺点是确实存在的。 |
 |
6
GopherDaily 2020-10-27 23:52:23 +08:00 3
实话说的话，就是菜
|
 |
7
chendy 2020-10-28 00:04:05 +08:00 1
当处理不好时区还有其他一些奇怪的问题的时候，字符串就是最优解，数字性能更好一些但是也更麻烦一点
|
 |
8
xcstream 2020-10-28 04:58:48 +08:00
比如查找 10 点到 11 点的数据 ， 用 int 存就要每个日期计算一遍。
|
 |
9
chenluo0429 2020-10-28 08:00:56 +08:00 via Android 1
1%的可能是有特殊需求，99%都是因为菜吧
|
 |
10
krixaar 2020-10-28 08:14:20 +08:00
如果他们存“20201027T195800+0800”也就是再加点无关紧要的佐料是不是就觉得没问题了？毕竟如果确实只在东八区用，+0800 写不写都知道。
|
 |
11
ragnaroks 2020-10-28 08:35:35 +08:00
这说明瓶颈在 web 应用上,不在数据库上
|
 |
12
opengps 2020-10-28 08:38:31 +08:00 via Android
没什么菜不菜的，只是偷懒而已
|
 |
13
xuanbg 2020-10-28 08:57:38 +08:00 1
对于接口来说，日期要么字符串传参，要么时间戳传参。还能有别的办法传参？反正我倾向于字符串传参，时间戳还得换算一下才能知道时间，不利于发现问题。
|
 |
14
blless 2020-10-28 09:11:46 +08:00 1
写业务多了就会发现时间戳的好处了，尤其是处理一些面向海外的业务
|
 |
15
zsdroid 2020-10-28 09:59:13 +08:00
时间戳不可读？加个虚拟列就好了
|
 |
16
wysnylc 2020-10-28 10:21:21 +08:00
@GopherDaily #6 +1 就是菜
时间戳有时区而且索引比字符串要快得多,字符串是索引性能最低的,要不然要那么多整数类型干什么 |
 |
17
wilsonWei 2020-10-28 11:18:14 +08:00
应该用带时区的 timestamp
|
 |
19
no1xsyzy 2020-10-28 12:55:05 +08:00
@xuanbg 有是有，json 的方式传{}或者传[]都可以的。
比如传 [2020, 10, 27, 19, 58, 00] 还比主题的格式更方便眼 parse 当然，ISO 8601 也是好的 只是觉得主题这样毫无 “肉眼解析锚点” 的方式确实不太行。 不过数据库是另一个问题，有日期格式优先日期格式，没有再看数据量级和需求综合分析，指不定最优方案是同时存储 timestamp 和字符串表示呢。 |
 |
20
GrayXu 2020-10-28 12:59:32 +08:00
字符串不是显然解析开销比较大嘛。。
|
 |
22
Kr98 2020-10-28 13:30:30 +08:00 via Android
@wilsonWei timestamp 是以 utc 为基准点，datetime 类型+时区是数据库的功能，和 timestamp 无关。
|
|
23
wilsonWei 2020-10-28 14:14:18 +08:00
@Kr98 我说的带时区的 timestamp，指的是数据库的字段类型：timestamp with time zone，并非 unix 时间戳
|
|
27
cmdOptionKana 2020-10-28 15:06:12 +08:00
@xuanbg 不可能吧，ISO8601 对前端非常友好，js 标准库就支持 ISO8601，最流行的日期时间库 day.js 也重点支持 ISO8601 。
|
 |
29
a719031256 2020-10-28 15:47:01 +08:00
太懒了
我手上的项目就遇到，给建表的人说字段属性跟注释有歧义，然后这家伙就直接把所有字段属性改为 varchar，所有的值含义都通过口口相传 |
|
30
wilsonWei 2020-10-28 15:55:23 +08:00
@a719031256 好家伙。。这规范也太差劲了，没人管管吗。。。
|
|
31
a719031256 2020-10-28 15:57:29 +08:00
@wilsonWei 管什么，国企的开发只要文档够标准就行了，至于代码和数据库设计将就效率而不是质量，文档要求每一个功能点要够详细，截图要多。。。。
|
|
32
CRVV 2020-10-28 16:09:06 +08:00 1
@v2webdev
用整数的话，32 位不够，那就要用 64 位的，占 8 bytes 那个字符串是 14 个数字，14 bytes 如果用定长的字符串，也就是不需要额外存长度，也不需要在结尾补一个 0，那就是差 6 bytes |
 |
33
ETiV 2020-10-28 16:13:53 +08:00 via iPhone
存时间戳
海外不仅跨时区，遇到有夏令时的地方有的搞了… |
|
34
wilsonWei 2020-10-28 16:22:09 +08:00
@a719031256 好吧，追求不一样
|
|
35
a719031256 2020-10-28 16:26:33 +08:00
@wilsonWei 这些人就是懒，啥事都是扔给我们帮他们弄，还有另一个人脸识别项目，海康 sdk 部署 Linux 环境居然不知道把动态库扔到系统库中，还要让我周六帮他弄，明明海康的文档写得清清楚楚
|
|
36
wilsonWei 2020-10-28 17:45:50 +08:00
@a719031256 这些大爷们就是懒，工作一点都不上心
|
Select Language