代码之家 › 专栏 › 技术社区 › Kenoyer130

使用varchar(max)作为存储过程参数是个好主意吗?

stored-procedures tsql

6

Kenoyer130 · 技术社区 · 16 年前

我有一个存储过程,它获取一个由管道分隔的ID数组的字符串并对其进行解析。我希望在一个事务中发生这种情况,所以不希望一次一个地传递它们。

如果我使用varchar(max)作为不限制传入参数的大小,这会导致问题吗?我看不到被击中的限制,但我也不想猜测或对字符串设置任意限制。

CREATE PROCEDURE myProc
    @IDs varchar(max) 
AS

BEGIN
  ...
END
GO

5 回复 | 直到 16 年前

1

3

John Leidegren 16 年前

没什么大不了的。 varchar(max) 行为就像任何少于8000个字符的varchar,直到超过8000个字符。两者之间应该没有什么差别 varchar(200) 和 varchar(最大) 如果实际数据少于8000个字符。如果你期望的是较小的输入,但不能排除较大的输入, varchar(最大) 很好。

2

n8wrl 16 年前

我不知道它是否会导致问题,但我更喜欢使用XML将多个元素“数组”的数量传递给存储过程。它使它更清楚地知道它是什么类型的数据,并且有很好的SQL-XML工具可以将XML“转换”成一个可以连接的伪表。然后,从管道分隔的XML转换就可以在数据库外部进行。

3

1

KM. 16 年前

如果您在SQL Server 2008上,那么我将使用表值参数。如果不是,我总是倾向于使用尽可能小的大小,但是我不明白为什么max作为存储过程参数会导致任何问题。如果您希望参数的长度实际上是无限的,那么可以使用max。

4

0

Spooks 16 年前

我使用varchar(max)当我不知道极限(这就是它的作用)时。总是很好地将变量设置为一定的长度,但是如果未知,这是可以接受的,并且不会导致任何问题,除了您的数据库增长了一点,人们能够在

5

-1

Community Mohan Dere 9 年前

TSQL不是一种很好的字符串操作语言,它的性能也很好(而且代码也很好!)最好在数据库外部解析字符串-so+1到 n8wrl's answer . 但本质上,使用 varchar(max) 为了这个。

除了使用像N8WRL建议的XML之外,还有 Table Valued Parameter 如果您使用的是SQL Server 2008,这可能是一个不错的选择。