事情開始得很簡單。MegaWare公司市場部門想要一個新的網站來發布文檔，開發團隊覺得使用SQL Server 2000數據庫作為文檔存儲倉庫會使事情變得簡單。Steve是MegaWare的數據庫管理員，沒有看出這有什麼大問題;在數據庫中存儲文檔，而不是使用文件系統，意味著服務器需要多做一些工作，但是它也會使得備份和管理容易得多。數據庫與文件系統變得不同步也應該是不可能的。
市場部門想要存儲的許多文檔都超過了8000個字節，那麼很明顯VARCHAR不是適合這項工作的數據類型。作為替代，TEXT數據類型被用來定義存放數據的字段。因為每個TEXT都能容納2GB的內容，TEXT要存放市場部門的同事們扔進數據庫的最大的文件也是沒有問題的。
數月過去了，市場用大量的無聊拷貝填滿了整個數據庫。但是這還不是Steve真正關心的問題。數據庫愉快地嗡嗡作響地運轉著，每個人對項目的結果都很滿意。
直到公司的標語改變的那個重大的日子。市場部的團隊認為“MegaWare: It’s really cool!”要比原來的“It’s MegaWare’s Way or the Highway!” 聽起來更好。因為市場部團隊已經將原來的標語嵌入了倉庫中每個文檔的頁腳上，現在Steve的工作就是更改所有這些文檔的頁腳。
“沒有問題，” Steve想，打開SQL Server 查詢分析器工具，執行了如下的T-SQL批處理:
UPDATE MarketingDocuments
SET Document =
REPLACE(Document,
’It’’s MegaWare’’s Way or the Highway!’,
’MegaWare: It’’s really cool!)
當他看到出現的錯誤消息的時候，Steve的輕松的微笑很快消失了，“替換函數的參數1，text數據類型無效。”
替換函數在編寫出來的時候，就對TEXT數據類型不起作用。同樣也對CHARINDEX或者SUBSTRING不起作用——或者至少是他們在超過8千個字符的情況下不起作用。更進一步地講，開發人員忘了處理TEXT或者IMAGE類型的本地變量;實際上不支持任何操作。即使是簡單地更新一個文檔中的一個子字符串都需要用到晦澀的東西，以及難以使用的類似READTEXT和WRITETEXT的函數。而不是開發人員或者忙碌的數據庫管理員因為想要弄清如何正確使用而采用了不同類型的函數消耗了時間。
SQL Server的開發人員很幸運，他們將會撥開烏雲見藍天。SQL Server 2005引入了一系列新的被稱為MAX的數據類型。這是VARCHAR，NVARCHAR和VARBINARY類型的擴展，這幾種類型以前被限制在8000字節以下。MAX可以容納高達2GB的數據，與TEXT和IMAGE一樣——並且完全兼容所有的SQL Server內置的字符串函數。
用MAX關鍵字定義一個某種MAX類型的變量與替代字符串的尺寸(為VARCHAR/NVARCHAR的時候)或者字節(為VARBINARY的時候)一樣簡單。
DECLARE @BigString VARCHAR(MAX)
SET @BigString = ’abc’
雖然這個變量可以自由地操縱，並且可以傳遞給任何的內置的字符串函數，兼容性仍然不是沒有問題。
首先，開發人員不能期望指定了尺寸的VARCHAR和VARBINARY變量在達到8000個字節的極限的時候可以自動“升級”到MAX版本。例如，如下的批處理:
DECLARE @String1 VARCHAR(4001)
DECLARE @String2 VARCHAR(4001)
SET @String1 = REPLICATE(’1’, 4001)
SET @String2 = REPLICATE(’2’, 4001)
SELECT LEN(@String1 + @String2)
4001+4001=8002，但是指定了尺寸的VARCHAR的極限是8000。因為這兩個變量中沒有一個是MAX類型，LEN函數的結果就是8000，不是8002。在將兩個變量連接的時候，一種簡單的修正方法就是聲明這兩個變量中的一個為VARCHAR(MAX)或者將其中的一個變量進行轉換。與一個規定了尺寸的類型進行連接的時候，優先考慮MAX類型，最終結果是MAX類型。所以，以下批處理的結果是8002，正如我們期望的一樣:
DECLARE @String1 VARCHAR(4001)
DECLARE @String2 VARCHAR(4001)
SET @String1 = REPLICATE(’1’, 4001)
SET @String2 = REPLICATE(’2’, 4001)
SELECT LEN(CONVERT(VARCHAR(MAX), @String1) + @String2)
在傳遞給字符串函數的時候，開發人員意識到字符串的原意在默認情況下是規定了尺寸的，而不是MAX類型，也是至關重要的。例如，以下查詢的結果就很令人驚奇:
SELECT LEN(REPLICATE(’1’, 8002))
因為字符串‘1’是被作為規定了尺寸的VARCHAR對待，而不是VARCHAR(MAX)，結果就是8000——但是在SQL Server 2005中，REPLICATE函數能夠產生高達2GB的字符串。要修正這個問題，可以將字符串轉換為VARCHAR(MAX)，這樣函數就會輸出同樣的類型了:
SELECT LEN(REPLICATE(CONVERT(VARCHAR(MAX), ’1’), 8002))
這個查詢現在將會返回期望的結果:8002。記住，總是要對采用了新特性編寫的代碼進行非常仔細的測試;隱藏的問題，例如上面描述的問題，可能並且毫無疑問地會在最壞的時間裡造成災難性的後果。
除了變量之外，MAX類型也可以用於定義表的字段:
CREATE TABLE BigStrings
(
BigString VARCHAR(MAX)
)
當用於表的時候，意識到MAX類型具有與TEXT和IMAGE類型稍微不同的行溢出行為是非常重要的。在SQL Server中，最大的行尺寸是8060字節。要超過這個限制，並且仍然管理每個都擁有高達2GB的存儲，用TEXT和IMAGE類型存儲的數據會被存儲引擎自動地斷行，在行裡只留下一個16字節的指針。這意味著行的尺寸是減少了，這對性能有好處。然而，檢索大數據是昂貴的，因為它不是與同一行的數據存放在同一個位置。
MAX數據類型在默認情況下，使用TEXT/IMAGE溢出行為和正常尺寸的VARCHAR/VARBINARY類型的行為的混合方式。如果一個字段的數據，加上表中所有其他字段的數據，總量少於8060字節，數據就存放在行內。如果數據超過8060字節，MAX字段的數據就會存放在行外。對於大字符串的表，以下的行將會與表中的其他數據存儲在同一個數據頁內:
INSERT BigStrings (BigString)
VALUES (REPLICATE(’1’,
8000))
But the following row will result in an overflow:
INSERT BigStrings (BigString)
VALUES (REPLICATE(CONVERT(VARCHAR(MAX), ’1’), 100000))
你可以更改MAX數據類型在每個表的基礎上的默認的行為，它們會表現得和TEXT和IMAGE類型一樣。這是通過使用sp_tableoption 存儲過程中的“大數值類型在行外”選項實現的。為了修改大字符串表以將MAX類型的處理方式變得與TEXT和IMAGE數據類型的處理方式相同，可以使用如下的T-SQL:
EXEC sp_tableoption
’BigStrings’,
’large value types out of row’,
’1’
看看定義一個MAX數據類型有多容易，與他們提供的靈活性一樣，一些數據設計師將會被引誘以下列的方式開始定義表:
CREATE TABLE Addresses
(
Name VARCHAR(MAX),
AddressLine1 VARCHAR(MAX),
AddressLine2 VARCHAR(MAX),
City VARCHAR(MAX),
State VARCHAR(MAX),
PostalCode VARCHAR(MAX)
)
設計師要注意了:不要這樣做!一個企業中的數據模型既應該包含有具有實際限制的數據，還要給用戶接口設計師有關字段尺寸的大致的指導。像這樣的表又該創建什麼樣的用戶接口呢?
除了數據整合和用戶接口含義之外，如果設計師這樣不必要地使用這些類型還會帶來性能上的損害。記住，查詢優化器使用字段的尺寸作為判斷優化查詢計劃的眾多標准之一。對於這個表，優化器幾乎沒有任何選擇。
所以，現在你知道了MAX數據類型為SQL Server 2005處理大數據增加了很大部分的靈活性。但是MegaWare的那個不幸的數據庫管理員，Steve會發生什麼變化?還在堅持使用SQL Server 2000，他開始更新簡歷，想象著如果更新表失敗了話，他的工作也就失去了。但是他也是幸運的——還有世界各地的MegaWare產品的擁護者——用GOOGLE的搜索可以很快地找到這篇文章《在TEXT字段中查找並替代》，這篇文章告訴他如何正確的進行更新。他花了整晚的時間來學習資料;再過幾個月之後，TEXT和IMAGE數據類型就僅僅是一段不愉快的記憶了。
