共计 2702 个字符，预计需要花费 7 分钟才能阅读完成。
作者：sp42a\
起源：https://zhangxin.blog.csdn.ne…
当设计一个产品，其中很多中央要把日期类型保留到数据库中，如果产品有兼容不同数据库产品的需要，那么，该当怎么设计呢？
当然，首先想到的是，应用数据库的 Date 或 DateTime 类型，可是看看不同数据库这些类型间的区别吧，真让人望而止步。
MySQL 数据库：
它们别离是 date、datetime、time、timestamp 和 year。
- date：“yyyy-mm-dd”格局示意的日期值
- time：“hh:mm:ss”格局示意的工夫值
- datetime：“yyyy-mm-dd hh:mm:ss”格局
- timestamp：“yyyymmddhhmmss”格局示意的工夫戳值
- year：“yyyy”格局的年份值。
范畴：
- date“1000-01-01”到“9999-12-31”3 字节
- time“-838:59:59”到“838:59:59”3 字节
- datetime“1000-01-01 00:00:00”到“9999-12-31 23:59:59”8 字节
- timestamp 19700101000000 到 2037 年的某个时刻 4 字节
- year 1901 到 2155 1 字节
Oracle 数据库：
Date 类型的外部编码为 12
长度：占用 7 个字节
数据存储的每一位到第七位别离为：世纪，年，月，日，时，分，秒
TIMESTAMP 是反对小数秒和时区的日期 / 工夫类型。对秒的精确度更高
TIMESTAMP WITH TIME ZONE 类型是 TIMESTAMP 的子类型，减少了时区反对，占用 13 字节的存储空间，最初两位用于保留时区信息
INTERVAL 用于示意一段时间或一个工夫距离的办法。在后面有屡次提过。INTERVAL 有两种类型.
- YEAR TO MONTH 能存储年或月指定的一个时间段.
- DATE TO SECOND 存储天, 小时, 分钟, 秒指定的时间段.
sql server：
datetime 和 smalldatetime
- datetime 数据类型所占用的存储空间为 8 个字节，其中前 4 个字节用于存储 1900 年 1 月 1 日以前或当前的天数，数值分正负，负数示意在此日期之后的日期，正数示意在此日期之前的日期；后 4 个字节用于存储从此日零时起所指定的工夫通过的毫秒数。
- smalldatetime 数据类型应用 4 个字节存储数据。其中前 2 个字节存储从根底日期 1900 年 1 月 1 日以来的天数，后两个字节存储此日零时起所指定的工夫通过的分钟数。
- smalldatetime 数据类型与 datetime 数据类型类似，但其日期工夫范畴较小，从 1900 年 1 月 1 日到 2079 年 6 月 6 日。此数据类型精度较低，只能准确到分钟，其分钟个位为依据秒数四舍五入的值，即以 30 秒为界四舍五入。
如果没有兼容多种数据库这个要求，我会毫不犹豫的应用数据库的 Date 类型。因为如果应用 Java 框架产生代码，对数据库中定义为 Date 类型的字段，甚至能在页面上产生出 JS 的工夫抉择框，确实能节俭很多开发工夫。而兼容不同数据库，就心愿产品在由一种数据库，迁徙到另外一种数据库时，尽可能小的代价，应用了 Date，看来就很艰难了。
有一个疑难，不晓得目前风行的 ORM 对这个解决得是不是好？因为工作不怎么波及这方面，所以不大理解。
另外，Java 系列面试题和答案全副整顿好了：
https://www.javastack.cn/mst/
在之前的设计开发中，因为有反对多种数据库这种需要，所以首先否定了日期工夫这样的类型。
已经应用过毫秒数（Java 的 System.currentTimeMillis()）这种形式，然而选用这个形式，思考的不是应用起来是否不便或者数据迁徙，而是思考到上面的起因：
Java 取到的毫秒数是对工夫点的一种精确形容。定义如下：java.lang.System.currentTimeMillis()，它返回从 UTC 1970 年 1 月 1 日午夜开始通过的毫秒数。
咱们能够看到，这个定义，保障了这个工夫值可能被后续设计开发的人员正确和精确的了解，可能为所有的利用正确理解，可能在所有时区上正确反映为失常的工夫模式。
过后的产品设计是有海内客户的，所以过后的设计，在数据库里保留的，应该是一个“精确的工夫”。例如“20120926080000”实际上并没有严格的示意出工夫，因为北京工夫 2012 年 9 月 26 日 8 点和格林威治工夫 2012 年 9 月 26 日 8 点显然是不一样的。
尽管咱们都是在一个确切的时区里，例如中国都是应用东八区工夫，然而须要思考的是：
- 有些产品是可能有海内客户的
- 产品所运行的机器，时区的设置未必都是东八区。
在这种状况下，如果数据库里的工夫不精确，会给程序运行带来问题。这种形式最大的毛病在于：
- 不不便对工夫进行分组查问，比方按月统计、按季 统计
- DBA 在保护时，不能直观的依据返回的行后果，看到简单明了的后果（看到的是毫秒数）
应用这种形式的特点是就义一点易用性和可了解性（不易于保护和了解），满足了查问后果的直观性和准确性要求，同时最大限度思考运行效率。为了解决这个问题，我设计了一个辅助的措施，就是建设一个数据库函数来进行工夫转换，把毫秒数的工夫转为制订时区和格局的工夫串，DBA 在保护时能够应用。测试了 Oracle 和 DB2 上，都能够这样。例如之前的查问的时候为：
SELECT username,user_addtime from userinfo这个查问显示的是毫秒数，应用内置函数后写成：
SELECT username,date2str(user_addtime) from userinfo这样返回的就是东八区、事后定义好格局的字符串了。
在之后的设计里，还应用过 YYYYMMDDHHmmSST 格局，其中的“T”指时区，退出时区，带来的影响有：
- 日期工夫字段就不能在应用数值来存储了，字符串比数字存储和检索的效率都要低。
- 应用程序须要加上额定的解决
带来的益处是：
- 便于 DBA 保护
- 到什么时候，即使没有看到数据库设计文档，都能看明确并精确了解数据库中一条信息中，这个字段保留到确切信息
应用这种形式的特点是就义一点效率，满足了查问后果的直观性和准确性要求。
总结一下，字段类型的抉择，还是依据场景的须要来抉择，从性能、效率要求、继续开发的要求、保护的要求几个方面综合思考。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
