使用正确的資料類型

大家應該都能正确的使用資料類型，這看起來似乎是非常簡單的事情。但不幸的是，它很容易讓你變得很困惑。舉個簡單的例子，如果運作此查詢：

SELECT a.ModifiedDate

FROM Person.Address AS a

WHERE a.AddressID = ;
           

輸出是這樣的:

這樣正常嗎？你會在上面看到年、月、日，緊跟着時間是以小時、分鐘和秒作為一個小數被顯示。在這裡有一個問題，此查詢應該是報告系統的，并且他們也隻關心日期的值。位址表已被修改，是以他們不希望看到時間。另外，一些人也很挑剔。他們很不喜歡看到日期格式化的這種方式。他們更傾向于看到“2009年1月20日”。

然而最簡單的辦法就是隻需要改變varchar列。你可以修改時間和所需的輸出格式。問題就解決了，這很容易…

直到有人輸入“Janry 2009”稍微重整了拼寫，這時你的報告會看起來很亂。或者他們要你在最後2個星期開始做篩選。無論何時運作報告，你現在都不能很容易在列上做日期計算。即使你克服這個問題，使用CAST格式化(連同ISDATE 試圖捕獲所有那些現已在系統中的錯别字)你會發現性能是非常緩慢的，是以你得在列上做索引，現在你有一個50位元組寬的索引鍵而不是3個位元組的日期資料類型，這樣會使索引效率更低。

關于這樣的例子數不勝數，你會遇到一些問題，并且你試圖做的一個格式化，通過使用varchar資料類型的DATETIME或DATE，使資料看起來很漂亮。這種事情經常發生，尤其是在剛剛開始。規則應該很簡單，使用正确的資料類型來收集資料。然而，這樣很容易分心和被推動。把它放在這種格式上，你能做到這點的唯一辦法是通過更改資料類型。

花時間去了解處理資料類型的含義。這不僅僅是日期和時間所導緻的問題。很多的東西可以很容易地塞進varchar字段，更準确的說應該是整數或小數或其他資料類型。它能夠與業務做很好的溝通，使他們明白不僅僅是困難，你想要保護的是功能和資料的完整性。顯示如何使用用戶端工具進行格式化。這個決定将能解釋所有下遊問題。然後，使用正确的資料類型來存儲資訊。

原文：Use the Correct Data Type