存日期會用 char,可以拉大容許值,比如 0000-00-00 00:00:00 ~ 9999-99-99 99:99:99 就是允許的。雖然真實時間日期根本不可能出現這種值,但也正因為如此,反而可以做些特殊用途。
至於存一串128bit的二進位碼、存加密後的資料,雖然有 binary 可以更貼近檔案格式,不過用 CHAR/VARCHAR 也沒什麼不好吧?而布林值雖然也有些 DB 支援用 enum 或甚至 bit,用 char 其實速度反而更快。
全面使用 char/varchar,我想除了以上個別考量之外,應該還有一個重要目的:抽換資料庫(比如 MSSQL 改換 Oracle) 幾乎沒什麼成本。
char 格式, 資料不足長度者後面補空白,儲存空間固定
varchar 格式資料實際之內容,儲存空間不固定
單就儲存空間上來看
char(5)
寫入 'ab' 資料庫為 'ab ' 5 byptes # 會多存3個空白
寫入 'abcd' 資料庫為 'abcd ' 5 byptes # 會多存1個空白
寫入 'abcde' 資料庫為 'abcde' 5 byptes
寫入 'abcdef' 資料庫為 'abcde' 5 byptes
varchar(5)
寫入 'ab' 資料庫為 'ab' 3 byptes # 多 1 byte 是存長度
寫入 'abcd' 資料庫為 'abcd' 5 byptes
寫入 'abcde' 資料庫為 'abcde' 6 byptes
寫入 'abcdef' 資料庫為 'abcde' 6 byptes
所以並不是使用 varchar 就一定會省空間。因此在儲存固定長度的資料時
使用 char 反而比較省空間。就如你所說的存日期時都是固定長度資料
或是存128bit的二進位碼時也是固定長度資料
這時後使用 char 當然會比較好!
至於效率...以固定長度的資料來看
透過 char 來讀取只需要讀取 n 個 bytes
透過 varchar 來讀取時長度 < 255 則為 n + 1 個 bytes
當 > 255 並且 < 65535 時 則為 n + 2 個 bytes..依此類推
這時後讀取效率就可以知道哪一個比較好了吧!!
日期與時間的欄位
用 datetime 就好了
也方便下 where 的篩選條件
至於存128bit的二進位碼
怎麼不用 binary(16) 呢?
wiseguy 說的好!節省資料庫轉移成本,甚至可同時支援多種資料庫!
尤其是日期使用字串方式,當只個別比對年份、月份、日期時,語法與效能應該會更好!
我不認識你們的dba,但是,可以猜到,他在Database這個領域工作應該很久了..
若不是很久,那就是剛好相反,他不太會用資料庫欄位屬性..
...
工作很久的DBA,只用這兩個欄位,有其道理,但總歸一句話,他對每個欄位都有他自己的一套解譯工具,能完全的掌控,這比資料庫的的掌控,可能都來的精準...
...
這是從過去使用ISAM File的時代所體會出來的道理..
希望對你有所幫助..
從"抽換資料庫(比如 MSSQL 改換 Oracle) 幾乎沒什麼成本" 角度看,
這是偶爾為之的事,
但date用char or varchar 儲存 以程式開發來說 卻要一直做轉換前的檢核,
因為是 char or varchar 就無法完全避免 非日期存入,
當存 非日期 會造成程式文字轉換日期錯誤,
做時區轉換也是困擾,
程式完整性來說一定要做資料檢核處理,是每每用到這個資料時都要做一次.
就效能及空間來說 hitomitanaka 資料庫日期資料使用日期型態與字元型態存放的比較,
做了一些說明
所以為什麼 你們的DBA愛char,
可能
我的經驗是
1.存日期用CHAR
以前寫程式會用民國年寫程式,所以都用char來作業。因為舊系統在民國100年後改寫,有人就改用西元年了,所以新的dba會選datetime來存
2.存一串128bit的二進位碼用CHAR(128):這我們沒用過
3.存加密後的資料用VARCHAR(64):加密後的資料,長度不確定的話也只能用VARCHAR來存
4.存布林值用CHAR:
布林值應該也是類似舊系統遺留的,原來不習慣用布林值存檔,習慣上 例如
欄位 處理否 你們會用布林值 T/F 還是用Y/N
還有些是狀態有很多種的 OP CM CL....
新時代 以後就交給你們了
以我來說,我為什麼愛用VARCHAR,不是我愛用,是因為字串與數值轉換上這樣程式
比較好寫,要不是這樣我一張表一百多個欄位我也不想一個一個改成VARCHAR
因為這樣,程式比較好寫,如此而以,我記得上次我在做欄位形態轉換的時候鳥毛問題一堆,度濫全部改成VARCHAR,瞬間...世界清淨了....應該是我程度不夠我也懶的想其他方法了...
以上是我為什麼要用VARCHAR的理由之一.