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

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

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

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

“沒有問(wèn)題，” 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)的錯(cuò)誤消息的時(shí)候，Steve的輕松的微笑很快消失了，“替換函數(shù)的參數(shù)1，text數(shù)據(jù)類型無(wú)效。”

替換函數(shù)在編寫出來(lái)的時(shí)候，就對(duì)TEXT數(shù)據(jù)類型不起作用。同樣也對(duì)CHARINDEX或者SUBSTRING不起作用——或者至少是他們?cè)诔^(guò)8千個(gè)字符的情況下不起作用。更進(jìn)一步地講，開發(fā)人員忘了處理TEXT或者IMAGE類型的本地變量;實(shí)際上不支持任何操作。即使是簡(jiǎn)單地更新一個(gè)文檔中的一個(gè)子字符串都需要用到晦澀的東西，以及難以使用的類似READTEXT和WRITETEXT的函數(shù)。而不是開發(fā)人員或者忙碌的數(shù)據(jù)庫(kù)管理員因?yàn)橄胍迦绾握_使用而采用了不同類型的函數(shù)消耗了時(shí)間。

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

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

DECLARE @BigString VARCHAR(MAX)

SET @BigString = 'abc'

雖然這個(gè)變量可以自由地操縱，并且可以傳遞給任何的內(nèi)置的字符串函數(shù)，兼容性仍然不是沒有問(wèn)題。首先，開發(fā)人員不能期望指定了尺寸的VARCHAR和VARBINARY變量在達(dá)到8000個(gè)字節(jié)的極限的時(shí)候可以自動(dòng)“升級(jí)”到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。因?yàn)檫@兩個(gè)變量中沒有一個(gè)是MAX類型，LEN函數(shù)的結(jié)果就是8000，不是8002。在將兩個(gè)變量連接的時(shí)候，一種簡(jiǎn)單的修正方法就是聲明這兩個(gè)變量中的一個(gè)為VARCHAR(MAX)或者將其中的一個(gè)變量進(jìn)行轉(zhuǎn)換。與一個(gè)規(guī)定了尺寸的類型進(jìn)行連接的時(shí)候，優(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ù)的時(shí)候，開發(fā)人員意識(shí)到字符串的原意在默認(rèn)情況下是規(guī)定了尺寸的，而不是MAX類型，也是至關(guān)重要的。例如，以下查詢的結(jié)果就很令人驚奇:

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

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

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

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

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

CREATE TABLE BigStrings

(

BigString VARCHAR(MAX)

)

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

MAX數(shù)據(jù)類型在默認(rèn)情況下，使用TEXT/IMAGE溢出行為和正常尺寸的VARCHAR/VARBINARY類型的行為的混合方式。如果一個(gè)字段的數(shù)據(jù)，加上表中所有其他字段的數(shù)據(jù)，總量少于8060字節(jié)，數(shù)據(jù)就存放在行內(nèi)。如果數(shù)據(jù)超過(guò)8060字節(jié)，MAX字段的數(shù)據(jù)就會(huì)存放在行外。對(duì)于大字符串的表，以下的行將會(huì)與表中的其他數(shù)據(jù)存儲(chǔ)在同一個(gè)數(shù)據(jù)頁(yè)內(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ù)類型在每個(gè)表的基礎(chǔ)上的默認(rèn)的行為，它們會(huì)表現(xiàn)得和TEXT和IMAGE類型一樣。這是通過(guò)使用sp_tableoption 存儲(chǔ)過(guò)程中的“大數(shù)值類型在行外”選項(xiàng)實(shí)現(xiàn)的。為了修改大字符串表以將MAX類型的處理方式變得與TEXT和IMAGE數(shù)據(jù)類型的處理方式相同，可以使用如下的T-SQL:

EXEC sp_tableoption

'BigStrings',

'large value types out of row',

'1'

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

CREATE TABLE Addresses

(

Name VARCHAR(MAX),

AddressLine1 VARCHAR(MAX),

AddressLine2 VARCHAR(MAX),

City VARCHAR(MAX),

State VARCHAR(MAX),

PostalCode VARCHAR(MAX)

)

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

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

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