數據庫：將日期存儲爲數字值

我正在考慮將一些日期值存儲爲整數。即201003150900數據庫：將日期存儲爲數字值

除了我失去了任何時區信息這個事實，還有什麼我應該關心他的解決方案嗎？使用此列的任何查詢都將很簡單，即「查找之後或之前」。即where datefield小於201103000000（明年3月以前）。

目前該應用程序正在使用MSSQL2005。任何指向陷阱的指針讚賞。

2010-03-15 Chin

使用正常的日期時間數據類型有什麼問題？ – 2010-03-15 01:21:30

我發現自己爲不同的UI /視圖解決方案做了很多時區偏移技巧。數據庫與應用程序主要使用的時區處於不同的時區。 – Chin 2010-03-15 01:34:02

重新設定不同的時區：以UTC存儲日期，'SELECT DATEDIFF（小時，GETDATE（），GETUTCDATE（））'找到偏移量，並從那裏開始。這樣當您的數據庫服務器和/或用戶移動時，沒有任何變化。 – tadamson 2010-03-15 01:57:32

使用適當的datetime數據類型將爲您提供更高效的存儲（smalldatetime消耗4個字節）和索引，並且會爲您提供語義更容易發展反對。你必須提出一個引人注目的論點，不要使用它們。

2010-03-15 01:24:11

不知道推測int必須小一些。謝謝。 – Chin 2010-03-15 01:35:46

'smalldatetime'和'int'都消耗四個字節，但你列出的例子日期不能用int表示 - 它太大了。很高興我能幫上忙。 – 2010-03-15 01:38:31

沒錯。謝謝 – Chin 2010-03-15 01:44:41

爲什麼不使用正確的UNIX timestamps？它們也只是整數，但它們不像201103000000那樣寬。

2010-03-15 01:21:17

+1使用既定的標準，而不是發明自己的標準。另外：一些操作 - 比如找到兩個日期之間的秒數 - 變得微不足道。 – 2010-03-15 01:23:43

有些操作 - 比如增加幾個月/年 - 幾乎不可能實現，無需將其重新設置爲日期/日期時間，並進行所有來回翻譯。內部表示已經是一個數字;爲什麼要推出自己的產品，並且必須自己寫圖書館？ – 2010-03-15 15:25:11

在2038上見到你 – 2011-07-06 18:47:10

只需使用DATETIME或SMALLDATETIME數據類型，它們就更加靈活。

2010-03-15 01:29:07 hallie

按照您建議的方式執行此操作的唯一原因是您的商業智能工具擁有時間維度成員名稱。如果這就是你打算使用它，那麼它是有道理的。

否則，像別人指出的那樣使用內置時間類型。

2010-03-15 01:41:53

回答