資訊專欄INFORMATION COLUMN
摘要：用這個(gè)類型還蠻方便的，一個(gè)是有很多內(nèi)置的函數(shù)和來處理它，比如宏，最關(guān)鍵的是在取數(shù)據(jù)的時(shí)候會自動幫你處理和時(shí)區(qū)的問題。至于用存時(shí)間，是另一種可行的方法，參見我個(gè)人不是很喜歡這么做，因?yàn)檫@樣你必須把模型中表示時(shí)間的成員聲明為類型。
先說一下mysql中DATETIME和TIMESTAMP的區(qū)別
TIMESTAMP是標(biāo)準(zhǔn)的unix timestamp，它存儲的是1970-1-1到現(xiàn)在經(jīng)過的秒數(shù)，4字節(jié)存儲。mysql用這個(gè)類型還蠻方便的，一個(gè)是有很多內(nèi)置的函數(shù)和trigger來處理它，比如CURRENT_TIMESTAMP宏，最關(guān)鍵的是在取數(shù)據(jù)的時(shí)候mysql會自動幫你處理DST和時(shí)區(qū)的問題。
DATETIME的范圍更大，好像可以從0000-00-00 00:00:00到9999-12-31 23:59:59，8字節(jié)存儲，當(dāng)然mysql內(nèi)部肯定也是用整數(shù)而不是字符串的（說了是8字節(jié)了），所以效率不是大問題。但DATETIME不帶時(shí)區(qū)，比如我在程序里生成了一個(gè)2015-05-07 15:26:00的時(shí)間（實(shí)際上是+8時(shí)區(qū)的，但這個(gè)對象可能是timezone naive）的，存到mysql里，再從不同時(shí)區(qū)的地方拿出來，這個(gè)時(shí)間可能就混了。
但TIMESTAMP也有兩個(gè)很大的問題：
4字節(jié)長度限制，它只能到2038年
很多時(shí)候我們希望根據(jù)用戶所在地的時(shí)區(qū)顯示時(shí)間而不是光顯示一個(gè)服務(wù)器時(shí)間
所以比較好的做法是，數(shù)據(jù)庫中使用DATETIME，然后存時(shí)間的時(shí)候一律用程序生成UTC時(shí)間（而不是local時(shí)區(qū)的時(shí)間）存進(jìn)去，取出來的時(shí)候不管想顯示服務(wù)器時(shí)間還是顯示用戶的時(shí)間都可以處理。
順便提一句，根據(jù)用戶所在地時(shí)區(qū)顯示時(shí)間有兩種做法：
當(dāng)用戶第一次訪問網(wǎng)站的時(shí)候，用js獲取時(shí)區(qū)發(fā)送到服務(wù)器上存到session里
用js處理時(shí)間的顯示（我覺得這種比較方便一點(diǎn)，畢竟不用改服務(wù)端代碼）
使用這種做法的唯一缺點(diǎn)是sqlite3沒有internal的DATETIME類型，所以在ORM框架如sqlalchemy中，它會直接存字符串進(jìn)去。（sqlite3的文檔也說，你要么存成int要么real要么字符串）。盡管這可能帶來一些不方便和性能的下降，但我認(rèn)為還是符合“keep it simple and stupid”的原則。
至于用INT存時(shí)間，是另一種可行的方法，參見http://www.liaoxuefeng.com/article/0014132675721847f569c3514034f099477...
我個(gè)人不是很喜歡這么做，因?yàn)檫@樣你必須把模型中表示時(shí)間的成員聲明為int類型。這樣是比較不符合邏輯的（那些Date呀Datetime之類的類就沒有用了呀，最多就有個(gè)Dateutil就好了），而且會使得程序不易讀（臥槽這個(gè)publishedDate為什么是int，它到底表示的是時(shí)間嗎？）。總之見仁見智。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/17463.html
摘要：微信公眾號后端進(jìn)階，專注后端技術(shù)分享框架分布式中間件服務(wù)治理等等。 微信公眾號「后端進(jìn)階」，專注后端技術(shù)分享：Java、Golang、WEB框架、分布式中間件、服務(wù)治理等等。 老司機(jī)傾囊相授，帶你一路進(jìn)階，來不及解釋了快上車！ 我發(fā)現(xiàn)數(shù)據(jù)庫有些日期居然用字符串保存？于是跟幾個(gè)小伙伴討論了關(guān)于數(shù)據(jù)庫的日期應(yīng)該要怎么保存的問題，其實(shí)我一直都建議直接用數(shù)值保存時(shí)間戳，為什么我要這么建議呢？...
摘要：用戶場景國際版中各個(gè)倉庫分屬不同的城市，不同的城市所在時(shí)區(qū)不同，基于各個(gè)角色對數(shù)據(jù)的使用情況不一樣主要的用戶場景庫內(nèi)作業(yè)人員，倉庫是紐約倉，時(shí)區(qū)是，查詢到的倉庫入庫單。在查詢結(jié)果顯示的時(shí)候，時(shí)間數(shù)據(jù)也需要轉(zhuǎn)換到紐約時(shí)區(qū)。 用戶場景 國際版中各個(gè)倉庫分屬不同的城市，不同的城市所在時(shí)區(qū)不同，基于各個(gè)角色對數(shù)據(jù)的使用情況不一樣主要的用戶場景庫內(nèi)作業(yè)人員，倉庫是紐約倉，時(shí)區(qū)是UTC-05:00...
摘要：用戶場景國際版中各個(gè)倉庫分屬不同的城市，不同的城市所在時(shí)區(qū)不同，基于各個(gè)角色對數(shù)據(jù)的使用情況不一樣主要的用戶場景庫內(nèi)作業(yè)人員，倉庫是紐約倉，時(shí)區(qū)是，查詢到的倉庫入庫單。在查詢結(jié)果顯示的時(shí)候，時(shí)間數(shù)據(jù)也需要轉(zhuǎn)換到紐約時(shí)區(qū)。 用戶場景 國際版中各個(gè)倉庫分屬不同的城市，不同的城市所在時(shí)區(qū)不同，基于各個(gè)角色對數(shù)據(jù)的使用情況不一樣主要的用戶場景庫內(nèi)作業(yè)人員，倉庫是紐約倉，時(shí)區(qū)是UTC-05:00...
閱讀 2362·2021-09-27 13:35
閱讀 618·2019-08-30 15:55
閱讀 869·2019-08-30 15:53
閱讀 614·2019-08-30 15:52
閱讀 2209·2019-08-30 12:59
閱讀 2349·2019-08-29 16:42
閱讀 1551·2019-08-26 18:26
閱讀 2525·2019-08-26 13:48
