本文是SQL Server 2005關於資料類型最大值問題的解決辦法的執行個體。
事情開始得很簡單。MegaWare公司市場部門想要一個新的網站來發布文檔,Team Dev覺得使用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的函數。而不是開發人員或者忙碌的資料庫管理員因為想要弄清如何正確使用而採用了不同類型的函數消耗了時間。