事情開始得很簡單。MegaWare公司市場部門想要一個新的網(wǎng)站來發(fā)布文檔，開發(fā)團隊覺得使用SQL Server 2000數(shù)據(jù)庫作為文檔存儲倉庫會使事情變得簡單。Steve是MegaWare的數(shù)據(jù)庫管理員，沒有看出這有什么大問題;在數(shù)據(jù)庫中存儲文檔，而不是使用文件系統(tǒng)，意味著服務(wù)器需要多做一些工作，但是它也會使得備份和管理容易得多。數(shù)據(jù)庫與文件系統(tǒng)變得不同步也應(yīng)該是不可能的。

市場部門想要存儲的許多文檔都超過了8000個字節(jié)，那么很明顯VARCHAR不是適合這項工作的數(shù)據(jù)類型。作為替代，TEXT數(shù)據(jù)類型被用來定義存放數(shù)據(jù)的字段。因為每個TEXT都能容納2GB的內(nèi)容，TEXT要存放市場部門的同事們?nèi)舆M數(shù)據(jù)庫的最大的文件也是沒有問題的。

數(shù)月過去了，市場用大量的無聊拷貝填滿了整個數(shù)據(jù)庫。但是這還不是Steve真正關(guān)心的問題。數(shù)據(jù)庫愉快地嗡嗡作響地運轉(zhuǎn)著，每個人對項目的結(jié)果都很滿意。

直到公司的標(biāo)語改變的那個重大的日子。市場部的團隊認(rèn)為“MegaWare: It's really cool!”要比原來的“It's MegaWare's Way or the Highway!” 聽起來更好。因為市場部團隊已經(jīng)將原來的標(biāo)語嵌入了倉庫中每個文檔的頁腳上，現(xiàn)在Steve的工作就是更改所有這些文檔的頁腳。

“沒有問題，” Steve想，打開SQL Server 查詢分析器工具，執(zhí)行了如下的T-SQL批處理:

UPDATE MarketingDocuments

SET Document =

REPLACE(Document,

'It''s MegaWare''s Way or the Highway!',

'MegaWare: It''s really cool!)

當(dāng)他看到出現(xiàn)的錯誤消息的時候，Steve的輕松的微笑很快消失了，“替換函數(shù)的參數(shù)1，text數(shù)據(jù)類型無效。”

替換函數(shù)在編寫出來的時候，就對TEXT數(shù)據(jù)類型不起作用。同樣也對CHARINDEX或者SUBSTRING不起作用——或者至少是他們在超過8千個字符的情況下不起作用。更進一步地講，開發(fā)人員忘了處理TEXT或者IMAGE類型的本地變量;實際上不支持任何操作。即使是簡單地更新一個文檔中的一個子字符串都需要用到晦澀的東西，以及難以使用的類似READTEXT和WRITETEXT的函數(shù)。而不是開發(fā)人員或者忙碌的數(shù)據(jù)庫管理員因為想要弄清如何正確使用而采用了不同類型的函數(shù)消耗了時間。

SQL Server的開發(fā)人員很幸運，他們將會撥開烏云見藍(lán)天。SQL Server 2005引入了一系列新的被稱為MAX的數(shù)據(jù)類型。這是VARCHAR，NVARCHAR和VARBINARY類型的擴展，這幾種類型以前被限制在8000字節(jié)以下。MAX可以容納高達(dá)2GB的數(shù)據(jù)，與TEXT和IMAGE一樣——并且完全兼容所有的SQL Server內(nèi)置的字符串函數(shù)。

用MAX關(guān)鍵字定義一個某種MAX類型的變量與替代字符串的尺寸(為VARCHAR/NVARCHAR的時候)或者字節(jié)(為VARBINARY的時候)一樣簡單。

DECLARE @BigString VARCHAR(MAX)

SET @BigString = 'abc'

雖然這個變量可以自由地操縱，并且可以傳遞給任何的內(nèi)置的字符串函數(shù)，兼容性仍然不是沒有問題。首先，開發(fā)人員不能期望指定了尺寸的VARCHAR和VARBINARY變量在達(dá)到8000個字節(jié)的極限的時候可以自動“升級”到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函數(shù)的結(jié)果就是8000，不是8002。在將兩個變量連接的時候，一種簡單的修正方法就是聲明這兩個變量中的一個為VARCHAR(MAX)或者將其中的一個變量進行轉(zhuǎn)換。與一個規(guī)定了尺寸的類型進行連接的時候，優(yōu)先考慮MAX類型，最終結(jié)果是MAX類型。所以，以下批處理的結(jié)果是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)

在傳遞給字符串函數(shù)的時候，開發(fā)人員意識到字符串的原意在默認(rèn)情況下是規(guī)定了尺寸的，而不是MAX類型，也是至關(guān)重要的。例如，以下查詢的結(jié)果就很令人驚奇:

SELECT LEN(REPLICATE('1', 8002))

因為字符串‘1’是被作為規(guī)定了尺寸的VARCHAR對待，而不是VARCHAR(MAX)，結(jié)果就是8000——但是在SQL Server 2005中，REPLICATE函數(shù)能夠產(chǎn)生高達(dá)2GB的字符串。要修正這個問題，可以將字符串轉(zhuǎn)換為VARCHAR(MAX)，這樣函數(shù)就會輸出同樣的類型了:

SELECT LEN(REPLICATE(CONVERT(VARCHAR(MAX), '1'), 8002))

這個查詢現(xiàn)在將會返回期望的結(jié)果:8002。記住，總是要對采用了新特性編寫的代碼進行非常仔細(xì)的測試;隱藏的問題，例如上面描述的問題，可能并且毫無疑問地會在最壞的時間里造成災(zāi)難性的后果。

除了變量之外，MAX類型也可以用于定義表的字段:

CREATE TABLE BigStrings

(

BigString VARCHAR(MAX)

)

當(dāng)用于表的時候，意識到MAX類型具有與TEXT和IMAGE類型稍微不同的行溢出行為是非常重要的。在SQL Server中，最大的行尺寸是8060字節(jié)。要超過這個限制，并且仍然管理每個都擁有高達(dá)2GB的存儲，用TEXT和IMAGE類型存儲的數(shù)據(jù)會被存儲引擎自動地斷行，在行里只留下一個16字節(jié)的指針。這意味著行的尺寸是減少了，這對性能有好處。然而，檢索大數(shù)據(jù)是昂貴的，因為它不是與同一行的數(shù)據(jù)存放在同一個位置。

MAX數(shù)據(jù)類型在默認(rèn)情況下，使用TEXT/IMAGE溢出行為和正常尺寸的VARCHAR/VARBINARY類型的行為的混合方式。如果一個字段的數(shù)據(jù)，加上表中所有其他字段的數(shù)據(jù)，總量少于8060字節(jié)，數(shù)據(jù)就存放在行內(nèi)。如果數(shù)據(jù)超過8060字節(jié)，MAX字段的數(shù)據(jù)就會存放在行外。對于大字符串的表，以下的行將會與表中的其他數(shù)據(jù)存儲在同一個數(shù)據(jù)頁內(nèi):

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數(shù)據(jù)類型在每個表的基礎(chǔ)上的默認(rèn)的行為，它們會表現(xiàn)得和TEXT和IMAGE類型一樣。這是通過使用sp_tableoption 存儲過程中的“大數(shù)值類型在行外”選項實現(xiàn)的。為了修改大字符串表以將MAX類型的處理方式變得與TEXT和IMAGE數(shù)據(jù)類型的處理方式相同，可以使用如下的T-SQL:

EXEC sp_tableoption

'BigStrings',

'large value types out of row',

'1'

看看定義一個MAX數(shù)據(jù)類型有多容易，與他們提供的靈活性一樣，一些數(shù)據(jù)設(shè)計師將會被引誘以下列的方式開始定義表:

CREATE TABLE Addresses

(

Name VARCHAR(MAX),

AddressLine1 VARCHAR(MAX),

AddressLine2 VARCHAR(MAX),

City VARCHAR(MAX),

State VARCHAR(MAX),

PostalCode VARCHAR(MAX)

)

設(shè)計師要注意了:不要這樣做!一個企業(yè)中的數(shù)據(jù)模型既應(yīng)該包含有具有實際限制的數(shù)據(jù)，還要給用戶接口設(shè)計師有關(guān)字段尺寸的大致的指導(dǎo)。像這樣的表又該創(chuàng)建什么樣的用戶接口呢?

除了數(shù)據(jù)整合和用戶接口含義之外，如果設(shè)計師這樣不必要地使用這些類型還會帶來性能上的損害。記住，查詢優(yōu)化器使用字段的尺寸作為判斷優(yōu)化查詢計劃的眾多標(biāo)準(zhǔn)之一。對于這個表，優(yōu)化器幾乎沒有任何選擇。

所以，現(xiàn)在你知道了MAX數(shù)據(jù)類型為SQL Server 2005處理大數(shù)據(jù)增加了很大部分的靈活性。但是MegaWare的那個不幸的數(shù)據(jù)庫管理員，Steve會發(fā)生什么變化?還在堅持使用SQL Server 2000，他開始更新簡歷，想象著如果更新表失敗了話，他的工作也就失去了。但是他也是幸運的——還有世界各地的MegaWare產(chǎn)品的擁護者——用GOOGLE的搜索可以很快地找到這篇文章《在TEXT字段中查找并替代》，這篇文章告訴他如何正確的進行更新。他花了整晚的時間來學(xué)習(xí)資料;再過幾個月之后，TEXT和IMAGE數(shù)據(jù)類型就僅僅是一段不愉快的記憶了。