使用varchar（max）作爲存儲過程參數是個好主意嗎？

我有一個存儲過程，它需要一個由管道分隔的ID數組的字符串並將其解析出來。我希望在事務中發生這種情況，所以不要一次將它們傳遞給一個事務。使用varchar（max）作爲存儲過程參數是個好主意嗎？

如果我使用varchar（max）作爲不限制傳入參數的大小，這會導致問題嗎？我沒有看到被限制的命中，但我也不想猜測或對字符串進行任意限制。

CREATE PROCEDURE myProc 
    @IDs varchar(max) 
AS 

BEGIN 
    ... 
END 
GO

來源

2010-09-15 Kenoyer130

沒有太多。 varchar(max)的行爲與任何小於8000個字符的varchar相同，直到超過8000個字符。如果實際數據少於8000個字符，則在varchar(200)和varchar(max)之間應該幾乎沒有差別。如果你期望的是較小的輸入，但不能排除更大的輸入，varchar(max)非常棒。

來源

2010-09-15 20:56:14

我不知道這是否會造成問題，但我更喜歡用什麼量多元素「陣列」，以XML存儲過程來傳遞。它使它更清楚它是什麼類型的數據，並且有很好的SQL-XML工具可以將XML「轉換」爲可以加入的僞表。然後，從管道分隔 - > XML轉換可能發生在數據庫之外。

來源

2010-09-15 20:55:11 n8wrl

如果它是值的簡單列表（未多值）XML增添了不少額外的數據（所有的標籤）傳輸。 – 2010-09-15 20:58:12

我已經看到了有關使用XML出於這樣的目的的其他建議，但我會補充說，使用'VARCHAR（MAX）'絕對不會造成問題和-的自在。還有是「任意」限制（根據SQL Server聯機叢書[爲SQL Server 2005] 2147483647個字符），但它是作爲@KM說「幾乎無限的」。 – 2010-09-15 20:59:45

是的，我對使用XML的單個值列表留有遺憾。 – Kenoyer130 2010-09-15 21:07:48

我使用varchar（max）時，我不知道限制（那是什麼它的存在）。總是好的，具有一定的長度設置的變量，但如果不清楚這是可以接受的，並不會造成任何問題，除非你的數據庫不斷增長的有點大，人能夠欺騙在

來源

2010-09-15 20:55:33 Spooks

如果大數據量你在SQL Server 2008上，那麼我會使用一個表值參數。如果不是，我總是喜歡儘可能使用最小的尺寸，但我不明白MAX爲什麼會導致存儲過程參數出現問題。如果你希望這個參數的長度幾乎不受MAX的限制。

來源

2010-09-15 20:56:01

-1

TSQL不是一個好的字符串操作語言，並且在性能方面（和代碼明智的！），你最好在解析字符串之外的字符串 - 因此+1到n8wrl's answer。本質上，使用varchar(max)這沒什麼錯。

除了使用了XML像n8wrl建議，一個Table Valued Parameter可能是一個不錯的選擇，如果你使用SQL Server 2008的

來源

2010-09-15 20:58:09 womp

我想包裝在一個事務的處理，這樣就意味着我不想分析它的DB之外。 – Kenoyer130 2010-09-15 21:09:03

使用varchar（max）作爲存儲過程參數是個好主意嗎？

回答

相關問題