我们在Freenode进行了这次编程讨论,当我试图使用VARCHAR(255)来存储此格式的日期变量:D/MM/YYYY时,这个问题出现了。那么问题是为什么使用VARCHAR来存储日期会很糟糕呢?以下是一些优点:
- 编码速度更快。以前我使用DATE,但日期格式化真的很麻烦。
- 使用字符串比使用日期更加耗费计算资源?谁在乎,我们生活在Ghz时代。
- 从伦理上讲不正确(lolwut?)这是另一个用户告诉我的……
那么,您更喜欢使用哪种方式来存储日期?SQL VARCHAR还是SQL DATE?
我们在Freenode进行了这次编程讨论,当我试图使用VARCHAR(255)来存储此格式的日期变量:D/MM/YYYY时,这个问题出现了。那么问题是为什么使用VARCHAR来存储日期会很糟糕呢?以下是一些优点:
那么,您更喜欢使用哪种方式来存储日期?SQL VARCHAR还是SQL DATE?
为什么不用锤子钉螺丝呢?
因为锤子不是适合这项工作的正确工具。
VARCHAR版本的一些缺点:
当然,在您的个人项目中,您可以随意选择。在专业环境中,我坚持使用适合这项工作的正确工具。
当你的数据库有超过2-3百万行时,你就会明白为什么使用DATETIME比VARCHAR更好了 :)
简单来说,对于数据库而言,处理能力不再是问题。只有由于HDD寻道时间导致的数据库大小才是麻烦所在。
基本上,在现代硬盘上,如果读取的顺序是随机的(通常是这种情况),则每秒可以读取约100个记录,因此您必须尽一切可能减小数据库大小,因为:
最终,总是HDD的寻道时间会让您不堪重负。例如,带有许多行的简单GROUP BY查询在磁盘上执行可能需要几个小时,而在RAM中执行则只需几秒钟=>因为寻道时间。
对于VARCHAR,您无法进行任何搜索操作。如果您非常讨厌SQL处理日期的方式,只需在32位整数字段中使用Unix时间戳即可。您将拥有(基本上)使用SQL DATE字段的所有优点,只需使用所选的编程语言操纵和格式化日期,而不是使用SQL函数。
两个原因:
让我们以一个看起来像这样的记录集为例:
5/12/1999 | Frank N Stein
1/22/2005 | Drake U. La
10/4/1962 | Goul Friend
1/22/2005 | Drake U. La
10/4/1962 | Goul Friend
5/12/1999 | Frank N. Stein
10/4/1962 | Goul Friend
5/12/1999 | Frank N. Stein
1/22/2005 | Drake U. La
DATE/DATETIME
而不是VARCHAR
。但是有一个被忽视的第三种选择——将其存储为无符号整数INTEGER unsigned
!在我的上一个项目中,我决定使用INTEGER unsigned
,对于传递客户端和服务器之间的日期来说,这是最理想的类型。与其每次选择时都要将其转换回DATE
,不如直接选择并按照需要使用它。如果您想将日期选择为“人类可读”的日期,则可以使用FROM_UNIXTIME()
函数。此外,整数占用4个字节,而DATETIME
占用8个字节,节省了50%的存储空间。使用整数作为日期的存储方式也解决了Berin提出的排序问题。YYYY char(4), MM char(2), DD char(2)
,所使用的存储空间相同,并获得更多的索引选项。更好的方法是将字段存储为yyyy的short(4个字节),每个MM和DD都使用tinyint — 现在你只需要6个字节即可存储日期。当然,将日期组件分解为其组成部分的缺点是将其转换为适当的日期/时间数据类型比较复杂。