使用varchar（max）作为存储过程参数是一个好主意吗？

Question

我有一个存储过程，它接受一个由管道分隔的ID数组字符串并将其解析出来。我希望在事务中发生这种情况，所以不要一次一个地传递它们。

如果我使用varchar（max）来限制传入的参数的大小，这会导致问题吗？我没有看到限制被击中，但我也不想猜测或对字符串施加任意限制。

CREATE PROCEDURE myProc
    @IDs varchar(max) 
AS

BEGIN
  ...
END
GO

Answer 1

没有太大的意义。 varchar(max)的行为与任何小于8000个字符的varchar一样，直到超过8000个字符。如果实际数据少于8000个字符，则varchar(200)和varchar(max)之间应该没有差别。如果您期望较小的输入但不能排除较大的输入，则varchar(max)很棒。

Answer 2

我不知道它是否会引起问题，但我更喜欢使用XML将多少元素'数组'传递给sprocs。它使得它更清楚它是什么类型的数据，并且有很好的SQL-XML工具可以将XML“转换”为可以加入的伪表。然后，从管道分隔的转换 - ＆gt; XML可以在DB之外发生。

Answer 3

如果您使用的是SQL Server 2008，那么我将使用表值参数。如果没有，我总是喜欢使用尽可能小的大小，但我不明白为什么MAX会导致任何问题作为存储过程参数。如果您希望参数的长度实际上不受MAX的限制。

Answer 4

当我不知道限制时，我使用varchar（max）（那就是它的用途）。总是很好地设置一定长度的变量，但如果不知道这是可以接受的，并且不会导致任何问题，除了你的数据库增长一点点，以及人们能够在大量数据中填充

Answer 5

TSQL不是一个好的字符串操作语言，并且在性能方面（和代码明智！）你最好解析数据库之外的字符串 - 所以+1到n8wrl's answer。从本质上讲，使用varchar(max)对此没有任何不妥。

除了使用像n8wrl建议的XML之外，如果您使用的是SQL Server 2008，Table Valued Parameter可能是个不错的选择。